Best practices with Oracle and root access

[Geoff Wild]

I'm looking for some sort of an official document (link/whitepaper) around Best Practices with Oracle and root access.

IMHO - no one other then a sysadmin needs root access.

I don't want this to be a rant, I'm looking for official doc(s)...so I can give to 1 Oracle admin who thinks he should have root access on the systems he supports.

Main reason - he doesn't want to "bother" us to run the root.sh script when doing installs or changes...

IMHO - why is it called root.sh - because Oracle (and SAP) want you to get a sysadmin to run that script for you.

Like I said, I don't need your opinions (as I'm sure they will be for the most part the same as mine) but I need some sort of document - and if it is from Orcale - so much the better - because this one DBA swears by everything put out by Oracle - IE - if Oracle says do this - he does.

Thanks...Geoff

[TwoProc]

I don't think he's EVER going to find a document that says it's best practice to give a DBA sysadmin access.

I'm pretty the manual(s) tell you to run root.sh, etc as root, or get one to run it for you, and that's about the whole of it.

[TwoProc]

I don't think he's EVER going to find a document that says it's best practice to give a DBA sysadmin access.

I'm pretty sure the manual(s) tell you to run root.sh, etc as root, or get one to run it for you, and that's about the whole of it.

[Jeff Schussele]

Hi Geoff,

We don't give DBAs root access - ever.
We set up sudo rules for them to allow them to *only* do what they need to do.
If the don't tell us everything they need to do they have to wait until the next iterartion of the sudoers rule.
In emergencies we give them a "temp" rule to do what they need and then remove it when done.

My $0.02,
Jeff

[Jeff_Traigle]

Quite honestly, this shouldn't be a matter of a best practice document to show him. It should be a clear security policy decision from management regarding separation of duties. Sys Admins don't touch the databases, especially as SYS or SYSTEM, and DBAs don't touch the systems as root. If management wants to play loosy-goosy with the privileges, that's their call, but, with SOX requirements, in most large organizations and many smaller ones the separation of accesses is a requirement and the information security folks will be rather harsh in their enforcement of compliance. Maybe you should send him to talk to them. :)

(BTW, I did a quick Yahoo! search and didn't find anything useful as far as a best practice document on the subject.)

[A. Clay Stephenson]

Even allowing root.sh under sudo is a huge security risk because it is a shell script that is writable by oracle and could easily be modified and then sudo'ed. Before I ever run root.sh, I cksum it against my "as delivered" versions. I basically create a wrapper that does this check and then allow them to execute root.sh. The wrapper runs under sudo and is not writable by anyone except root nor is the directory that houses this wrapper writable by anyone except root.

My general method of heading DBA's off at the pass is "Give my your sys and system passwords." Generally they look at me like I'm insane. I can't be allowed access to their database! If they do give me their passwords, I immediately tell them that I have no need of those passwords and their release of the passwords indicates that they are not nearly security conscious enough to be granted super-user passwords.
Either way, they can't win.

[Alzhy]

I use a timed and audited VNC session for my DBAs whenever they need root work.

Personally though - SysAdmins and really good UNIX persons make the best and most efficient Oracle DBAs. If you are a "good" DBA and you've no idea about the underlying OS and infrasrtcuture that you are runing your instance on - then how can you ensure your instance(s) is getting the best and proper environment. There are also tools/routines/teechniques that a UNIX/Admin savvy DBA can call/utilize to further improve productivity.

My few cents.

[Alzhy]

For some of their regular priveleged routines -- it sudo. We secure the scripts/files of course so they are not tempted to edit the script outside of change control.

[John Payne_2]

Oracle has written a check into their root.sh script that checks for the effective user to be root, and exits if it that's not the case.

Generally the installer creates a new /etc/oratab or modifies it. It also creates or modifies the /var/opt/oracle file. For these reasons, they require root. (That's my guess, anyway.) You can get around that, if you wanted, by making permissions of those files appropriate for them to run as oracle. (Whether you should do this is really a question for you, not me.)

The script generally only takes a few seconds to run, it doesn't take a whole lot of time. I let our DBA's run this as root-priviledged themselves. (Sorry Clay) That doesn't mean I let them do anything else, I only trust them about as far as I can throw them...

In the past, they used to always call to have us run the file.

Hope it helps
John

[Steven E. Protter]

You are right Geoff.

Oh and Shalom to you.

Oracle can be massively screwed up by having root access.

My Oracle DBA had root in Chicago because he was my backup. He never used it for dba tasks.

Note that Oracle sets up shared memory segments that you can view with the ipcs commands.

If the oracle dba does anything to a shared memory segment, runs the wrong utility as root or whatever, the segment is locked, the oracle user and database can not access it and the database crashes.

Very bad.

Now a doc. Or two.
http://www.google.co.il/group/comp.databases.oracle/browse_thread/thread/4ff31a8dfc6b58b7/16389f4eef802332%2316389f4eef802332?sa=X&oi=groupsr&start=2&num=3
Running root as internal
http://www.google.co.il/group/comp.databases.oracle.server/browse_thread/thread/d4d9a00908613f2c/475969081dafefd4%23475969081dafefd4?sa=X&oi=groupsr&start=1&num=3

A potential horror story:
http://lists.suse.com/archive/suse-oracle/2003-Mar/0189.html
http://www.oracle.com/technology/tech/linux/vmware/cookbook/stage2b_sles.html

The oracle dba's main reason is to not have to be root to run root.sh?

From experience and thats more important than any doc. You are right and he or she is wrong.