RE: "oracle" lockdown

From: Herring, David <>
Date: Wed, 26 Feb 2014 21:11:29 -0600
Message-ID: <>

If I said this is a problem I apologize for misstating the situation and I'm sorry for forcing you to rant. I was just wondering who else has gone through this and what to watch out for.

Dave Herring

-----Original Message-----

From: [] On Behalf Of Hans Forbrich Sent: Wednesday, February 26, 2014 7:27 PM To:
Subject: Re: "oracle" lockdown

I'm not sure what the problem is - Oracle database was designed to be administered by administrators using their own OS userid with checks that they are in the appropriate Administration OS group and this has been available since half of forever.

Other than installation and some patching, there generally should be no reason to log in as Oracle.

Indeed, the common habit (by many shops I visit) for DBAs to log in as user Oracle is terrifying from a security perspective - everyone in the DBA team, and potentially others, has the keys to the kingdom and there is absolutely no non-repudiation. No way at all to tell which admin did which command; everyone scrambling to get the changed password; getting an exception to the corp password change lifecycle policy; etc. And when a DBA leaves the group, the common-knowledge super user password needs to be changed, but often is not ...

Even in my lab, I have a non-'oracle' Oracle Administrator which I use for most admin (which seems silly in a one-man lab).

There is a reason we are forced to run during installation - mainly to chown files and setGID and config for 'sysdba' and 'sysoper' - to support DBAs and other support personnel using their own IDs. With 12c, they have given us additional groups to further refine the granularity.

ASM and GI take this a major step forward as well. In big shops with division of responsibility, that can be very useful although for small shops it get very cumbersome - "to run this I log in as A, but to run that I log in as B'. At that point Cloud Control and it's security model becomes very interesting.

A secondary variation on this - I also install an ORACLE_HOME specifically for the Oracle Client (sqlplus, etc) under user 'oraclient' (under a different tree - /u01/app/oraclient) which is not in OSDBA group to support batch jobs and non-admin users who need access to the machine. Users who log in then set up the environment for that and use Oracle Networking tcp, rather than bequeath adapter. That, however, can be a challenge for some things. </rant>

I would encourage the OP to set up a test user in the OSDBA group and check out the core scripts they run. Based on my experience, most of them should run just fine as long as the user is created properly and the environment is set up properly. I'd be interested in hearing under which circumstances this fails.


-- Received on Thu Feb 27 2014 - 04:11:29 CET

Original text of this message