Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
10  
Ask for a list of commands he needs then tailor your sudoers file to allow only those commands. –  dmourati Nov 13 '13 at 9:03
    
I'd say going the sudoers way, like suggested above, is clearly the right way. –  Sami Laine Nov 13 '13 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 '13 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 '13 at 10:39
5  
Your DBA needs the root password as much as you need SYSDBA access. –  Michael Hampton Nov 13 '13 at 16:42

3 Answers 3

up vote 11 down vote accepted
  • 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.

share|improve this answer
3  
you can use sudo and valid sudo rules instead of giving root access. –  Jiri Xichtkniha Nov 13 '13 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". –  coincoin Nov 13 '13 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 '13 at 17:38
3  
@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 '13 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 '13 at 10:34

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.

share|improve this answer

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.

share|improve this answer
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 '13 at 15:19
3  
@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. –  JakeGould Nov 13 '13 at 15:31
1  
@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". –  Ivan Nov 13 '13 at 15:40
    
Oracle is a steaming pile. The best docs out there are: puschitz.com –  dmourati Nov 13 '13 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. –  RobM Nov 14 '13 at 10:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.