RE: "oracle" lockdown

From: <>
Date: Thu, 27 Feb 2014 11:47:16 -0500
Message-ID: <>


My 2c here
You have 2 options that I have seen here and I would say of late this is a subject that has been very close to us :)

  1. The path that you are going - I am afraid that it is not going to be as straight forward. As the wrapper script will then end up as a set of toolkit because the wrapper script will have to have other scripts that will need to be called (whatever you wanted to run). Then will come logging requirements etc etc. That will then have to be maintained and all that.
  2. The other option for you would be to use a vendor tool.. Something like powerbroker. That’s what we have in place. Actually we have both variations :)

Both are equally valid. Just a matter of what makes more sense for your situation


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

From: [] On Behalf Of Herring, David Sent: Thursday, February 27, 2014 10:25 AM To: D'Hooge Freek
Cc:; Subject: RE: "oracle" lockdown

Yup, that's what I was thinking concerning a "wrapper" script, meaning it wraps around whatever you wanted to run, setting the env beforehand and cleanup afterwards. This would only be needed for this situations when you absolutely need to run as "oracle" and I'm still trying to narrow down exactly which situations those are.

Dave Herring

From: D'Hooge Freek [] Sent: Thursday, February 27, 2014 8:20 AM To: Herring, David
Cc:; Subject: Re: "oracle" lockdown


Could you create a script in which you first set the environment variables, followed by the actual command you need to run and then run that script as "oracle" user via sudo? If so, you only need a way to set the correct environment variables for a given database, which can be done via oraenv. For RAC / RAC One Node environments I have created a script (godb), which combines the oraenv script with the config in the GI to set the instance name correctly for the current node. Most recent stable version can be found here (ignore the test in the name  ;-)  ):

But I'm wondering what additional security they think to have by revoking the shell from the oracle user? I mean, if someone gets hold of the password of one of the dba's, they can still do anything they want via sudo, no?



Freek D'Hooge
Exitas NV
Senior Oracle DBA
tel +32(03) 443 12 38
On wo, 2014-02-26 at 15:17 -0600, Herring, David wrote:

Sorry if it wasn't clear about the differences in #1 (no logon as "oracle") and #2 (no shell). I'm not very familiar with details on all the settings for a Linux account but #2 was stressed to me and that as part of it/because of it we won't have the ability to run anything in cron as "oracle".

Other companies I've worked for have denied direct logon as "oracle" but you could still "su - oracle". Not in this case, only "sudo -u oracle <cmd>". Like I said before, I'm concerned about having all env variables set properly.

Mark, in situations like this in the past did you end up creating some sort of wrapper and pass commands to it as arguments? I'm still trying to figure out how to run commands out of $AGENT_HOME/bin or $ORACLE_HOME/bin or $GRID_HOME/bin, not knowing up front their exact definition and not knowing even if $ORACLE_HOME, $AGENT_HOME, $GRID_HOME will even be set.

Dave Herring

From: Powell, Mark
Sent: Wednesday, February 26, 2014 3:56 PM To: 'Andrew Kerber'
Subject: RE: "oracle" lockdown

I have worked under the sudo route.  That is not a problem instead of logging onto Oracle you log onto your own id.  Then you sudo - oracle. But that Oracle could run shell scripts and cron, etc.  Item #2 is really the same as #1.

From: Andrew Kerber [] Sent: Wednesday, February 26, 2014 3:51 PM To: Powell, Mark
Subject: Re: "oracle" lockdown

I believe what he is saying by 'no shell' is that no one can actually log in as Oracle.  That all commands must be run using the sudo command.  Im not sure you can successfully manage an oracle database that way.  At the very least it strikes me as painful.

On Wed, Feb 26, 2014 at 2:43 PM, Powell, Mark <> wrote: I do not think items and #1 and #3 are an issue since I have worked on systems like that, but I am not sure about item #2, "no shell."  What exactly does that mean?

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

From: [] On Behalf Of Herring, David Sent: Wednesday, February 26, 2014 3:20 PM To:
Subject: "oracle" lockdown


Our team is about to be placed in a more challenging situation where the OS account "oracle" will be locked down in the following ways:

  1.  No direct logons.
  2.  No shell can be created by "oracle".
  3.  Execution as "oracle" can be done by DBA accounts using: "sudo -u oracle <cmd>".

I'm tasked with coming up with a test plan for each environment converted over to this configuration.  While I can come up with the various commands we typically use off a consolidation of ~/.bash_history on all servers, I'm concerned about the environment when running "sudo - u oracle".  I'm told that there's no guarantee on what env variables will be set so if I expect any particular values I'll have to put it all in a script, since we can't run multiple commands on one line (like "sudo -u oracle export ORACLE_SID=dave; export ORAENV_ASK=NO; .oraenv; ...").

My first thought is we'll need some sort of wrapper script, with arguments for the ORACLE_SID and command line to run.  Has anyone run into this type of situation and if so how did you handle it?  There's still no word on how we're going to manage interactive installs.  I feel like I'm on the Indians in the movie "Major League".

Dave Herring




Please visit our website at for important disclosures and information about our e-mail policies. For your protection, please do not transmit orders or instructions by e-mail or include account numbers, Social Security numbers, credit card numbers, passwords, or other personal information.
-- Received on Thu Feb 27 2014 - 17:47:16 CET

Original text of this message