14

My Oracle DBA Colleague is requesting root access on our production servers.
He is arguing that he need it to perform some operations like rebooting the server and some other tasks.

I do not not agree with him because I've set him a Oracle user/group and a dba group where Oracle user belong. Everything is running smoothly and without the DBA having root access currently.
I also think that all administrative tasks like scheduled server reboot needs to be done by the proper administrator (The Systems administrator on our case) to avoid any kind of issues related to a misunderstanding of the infrastructure interactions.

I would like input from both sysadmins and Oracle DBAs - Is there any good reason for an Oracle DBA to have root access in a production environment?

If my colleague really needs this level of access I'll provide it, but I'm quite afraid of doing so because of security and system integrity concerns.

I'm not looking for pros/cons but rather advice on the how I should take to deal with this situation.

6
  • 12
    Ask for a list of commands he needs then tailor your sudoers file to allow only those commands.
    – dmourati
    Nov 13, 2013 at 9:03
  • I'd say going the sudoers way, like suggested above, is clearly the right way.
    – user192911
    Nov 13, 2013 at 9:24
  • I'll not using sudo, this is a restricted access and controlled sensitive server, I'll do it the hard way using POSIX Rights and Chrooted/limited prompt shell.
    – Dr I
    Nov 13, 2013 at 9:50
  • IMHO as a sysadmin I always go with the sudoers way and restrict access as far as possible. Better to start with the bare minimum and then add access to commands incrementally as needed. +1 @dmourati
    – sgtbeano
    Nov 13, 2013 at 10:39
  • 7
    Your DBA needs the root password as much as you need SYSDBA access. Nov 13, 2013 at 16:42

8 Answers 8

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

10
  • 3
    you can use sudo and valid sudo rules instead of giving root access.
    – jirib
    Nov 13, 2013 at 9:46
  • 3
    @Jiri : Having something like %dba ALL=(ALL) ALL in /etc/sudoers is actually giving root access. Listing a restricted set of command for dba is what I call "regular shell access".
    – user130370
    Nov 13, 2013 at 10:27
  • 2
    Oracle+docker sounds like a recipe for disaster. Sudo is not allowed? Sounds like whoever is restricting the environment has no idea wtf they are doing.
    – dmourati
    Nov 13, 2013 at 17:38
  • 4
    @DrI Removing sudo and giving people unrestricted root access is a pretty substantial step BACKWARDS in system security. I'll be frank, if your boss things sudo is "esoteric technology" they're an idiot.
    – voretaq7
    Nov 17, 2013 at 3:31
  • 1
    @voretaq7 I know that, but as I already said it, I'm working for a large corporation, not myself, so I do not handle every aspect of our IT and have to deal with my tools ;-) My main question was related to the NEEDS for DBA to have the root access, and most of people think the opposite, so I'll investigate futhermore on his needs ;-) and then deal with him for a compromised situation.
    – Dr I
    Nov 18, 2013 at 10:34
6

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.

4

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.

6
  • 4
    It's not the role of the DBA to reboot production servers, tweak the production server's kernel parameter, manipulate the production server storage, etc. His role is to define how a production server should be configured and let the implementation task to the sysadmins. Incident management that impact a production server should always go to the sysadmin, not the dba.
    – Stephane
    Nov 13, 2013 at 15:19
  • 6
    @Stephane In an ideal world, yes everyone’s roles are clearly defined. But in many cases, it’s not. And in the case of DBA work as described it might be that this DBA is being hired to tweak server level performance. Let’s face it: Not all sysadmins understand configuration optimizations for all apps in their control. But still, what rubs me the wrong way is the DBA’s desire for access without details. Massive red flag in my book. Nov 13, 2013 at 15:31
  • 2
    @Stephane Oracle is very specific in this case. It's requirements for kernels tuneables can be non-trivial, it has it's own LVM (called ASM) and moreover in case of Oracle RAC some of it's CLusterwares processes run with root privs and it also manipulates storage and NICs. Sometimes it's easier to let DBA execute vxdisk resize command then play email ping-pong in the middle of the night. It is more about trust and auditing then about "security".
    – ibre5041
    Nov 13, 2013 at 15:40
  • Oracle is a steaming pile. The best docs out there are: puschitz.com
    – dmourati
    Nov 13, 2013 at 17:35
  • 1
    If they're tweaking specific things to fix or improve specific issues then they should be testing/verifying these in a dev environment (and fine, give them root on that) then passing instructions to the sysadmin/ops team on what precisely should be done to the live environment to implement these changes once they're tested. And if they're not doing that, and are instead just playing around with settings until it works then nobody should be doing that on the live environment anyway.
    – Rob Moir
    Nov 14, 2013 at 10:56
1

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.

0

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.

0

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.

0

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

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .