Does my Oracle DBA need root access?

Solution 1:

• Who installs Oracle on the servers?
  If it's the DBA they need root access. If it's sysadmin, the DBA doesn't.

• Who is called late at night when database server is down?
  If you can't ensure sysadmins are available 24/7 you may want to give root access to the DBA.

Bear in mind that if your DBA already has shell access as a regular user (with or without some commands he can run via sudo; with or without being chrooted) that's enough to mess with the server (a bad guy stealing his account can fork bomb, exceed ulimit sending spam, drop the database, ...).

For all these reasons, I think in an ideal world DBAs should not have root access; but in the real world, they should at least always be able to obtain it in case of emergency.

Solution 2:

In general—and not specific to DBAs—anyone who demands root access without giving a valid reason is either:

1. Someone who doesn’t know what they are doing.
2. Arrogant & uncooperative.
3. Both of the above.

Now, there might be real reasons they need root access to handle their task, but again if they cannot explain why & put it in writing, I would not deal with them. Professionals who deal with servers understand & respect boundaries. Hot shots who know enough to get in trouble believe the rules apply to everyone but them.

In cases where I have had to tussle with folks like this, I have insisted that time be scheduled ahead of time so I could be on the server with them to handle issues as they arise. And this has actually worked well.

Another alternative—that might not be practical—is to create an exact clone of the server in question & give them root access on that. Be sure to change the password to something specific to them of course. Let them blow up an isolated development box.

But in general, if you are the one who will get called late at night to clean up a mess that this guy might create, then you have every right to say no to a blanket request for root access.

Solution 3:

Theoretically DBAs can work without root privs, but it is PITA for both sides. It is practically impossible to define list of command to be accessible via sudo.

Give DBAs root privs if:

• you do not want to be woken up in the middle of the night, just to reboot the server
• you want quick and smooth incident management
• if your sever is dedicated for DB server only

DBAs usally need root privs for: kernel parameters adjustments(sysctl), storage manipulation, problem investigation.

Proper auditioning ensure better run conditions, than strictly defined security rules. If you have auditing implemented you can always ask why they did/changed something. If you do not have auditing, you do not have security anyway.

EDITED

This a list of common Oracle requirements on standalone (non-clustered installations)

• Kernel parameters

  • Memory related (large/huge pages configuration, shared RAM(ipcs), non-swapable(locked) RAM)
  • networks related (sending/receiving window size, TCP keepalive)
  • storage related (number of open files, async IO)

  There might be about 15-20 sysctl parameters. For each of them Oracle provides a recommended value or an equation. For some parameters the recommended equation can change over the time(aync io) or in some cases Oracle provided more than one equation for the same parameter.

• Storage: Linux udev rules go not guarantee boot persistent device names. Therefore Oracle provided kernel driver and tools (AsmLib). These allows you na "label" physical partitions as root and then you can see these labels when administering database storage
• Problem investigation:
  • When database crashes because it can not open more file handles then the only solution is to increase kernel limit, execute 'sysctl -p' and then start the DB.
  • Also when you find that the physical RAM is too fragmented and database can not allocate large pages, then the only option is to reboot the server.
  • (DCD) - dead connection detection. For example on AIX netstat does not print PID. The only way how to pair a TCP connection with PID is kernel debugger.
  • glance (something like top on HP-UX) requires root privs
  • various Veritas level investigations
  • and many many others

It is up to you to decide how much time you will "waste" till the issue is resolved. I just wanted to point that the strong role separation can be very expensive is some cases. So instead of increasing the "security" focus on reducing risk and dangers. Which is not the same. Tools like ttysnoop or shell spy allow you to "record" the whole ssh session, thus they grantee undeniableness. This can serve better than sudo.