RE: "oracle" lockdown
- From: "Herring, David" <HerringD@xxxxxxx>
- To: "mark.powell2@xxxxxx" <mark.powell2@xxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Wed, 26 Feb 2014 15:17:07 -0600
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 [mailto:andrew.kerber@xxxxxxxxx]
Sent: Wednesday, February 26, 2014 3:51 PM
To: Powell, Mark
Cc: oracle-l@xxxxxxxxxxxxx
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 <mark.powell2@xxxxxx> 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: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Herring, David
Sent: Wednesday, February 26, 2014 3:20 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: "oracle" lockdown
Folks,
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
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
--
Andrew W. Kerber
'If at first you dont succeed, dont take up skydiving.'
--
//www.freelists.org/webpage/oracle-l
Other related posts:
