Does my Oracle DBA need root access?

• 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.

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.

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.

I am an Oracle DBA and my answer is, normally DBA doesn't need root access. But a RAC DBA? definitely he needs the root access to manage CRS, house keeping and all.

This question stems from back in a time when systems were much simpler and OS versus Database processes were separately defined and identifiable. System Administration and Database Administration duties and responsibilities were very distinct. With today’s IT environments and in particular, with today’s Database Servers, these duties and responsibilities, more often than not, tend to overlap. The System Administrator does due diligence to restrict “root” access with respect to “risk management”.

With today’s demands for “high availability” and “immediate remediation” for problems arise with our RAC Database Systems, the System administrators and Database Administrators serve their functional business communities, working together as a team. There should not be any concerns with “trust”, as both parties have a vested interest in keeping the RAC Database Servers on-line near 100% of the time. Bear in mind, the DBA already has shell access as a Database Administrator (with or without some commands he can run via sudo; with or without being chrooted), so obviously th DBA is a “trusted” agent. So, in reality the question should be, “Why doesn’t the Oracle DBA need access?”

Today’s DBA have taken on added responsibilities for the database server, where a Database Server is a member of an Oracle Real Application Cluster (RAC) and utilizes Oracle Automatic Storage Management (ASMLIB) to present shared storage across the RAC Database(s). Management of the RAC and ASM by the DBA relieves the already overworked System Administrator., which should be a welcomed contribution to the STS Group/Team.

And, as ibre5043 stated, "... 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." Also, you should ask who's monitoring the SSAs.

If the servers use Oracle Grid Infrastructure software such CRS, RAC or Oracle Restart, then many of the critical database services run as root, and many of the critical database configuration files are owned by root. It is an inherent design feature of the software. If this is a breach of your policies then the policies need to be revised.

The DBA will require root access to administer these features. Theoretically you could ask him for a list of the commands he will expect to run to be entered into Sudo, but the answer will be a very long list. Just take a look in $GRID_HOME/bin for a list of all binaries the DBA might use on a regular basis. If they're performing patching activities (which they should be) then the list could get even longer.

I have just submitted a similar question. Actually the reason a sysadmin does not want to give the root privilege, is the one of responsibility and accountability I think.

But if this is the cause, the the DBA should be also the one and only sysadmin. And the reason is simple. If there is a need for separation of accountability and responsibility, the sysadmin can ALWAYS be the DBA too. He can impersonate the oracle account, he can enter the database as SYSDBA and do whatever, without the need of the SYS or SYSTEM password.

So in my opinion, if there is a need for separation of sysadmins and DBAs, due to accountability and responsibility, the only logical cause is that the server should be also managed by the DBA and not the sysadmin. The server and the database should be as a whole the responsibility of the DBA, who should have also some system administration knowledge too.

If the server is used for more than hosting the database, and there is this need of separate responsibility and accountability, the this means trouble. But if the server is used only for hosting the database, then I see no reason why the DBA shouldn't have the root privilege, taken into account the myriad cases that he would need too.

Personally I would put the question the other way around. Why the sysadmin to have the root privilege on a dedicated database server? In fact, his specialty would be required in far less cases, than that of the DBA (with the root privilege).

Root access is required for Oracle grid installation and patching. There is no way around it. If there was a way to to grant temporary root access to a DBA for such needs, that would be ideal.