Re: "oracle" lockdown

From: Seth Miller <>
Date: Wed, 26 Feb 2014 17:06:01 -0600
Message-ID: <>


The product was designed so you don't need access to the installation account (oracle) unless you're doing things like installation.

Can you forward a list of commands that you believe you need the oracle account to execute? Perhaps the folks here can show you how to avoid using the oracle account all-together.

Most things not directly related to the binaries should not be installed with the oracle user. For example, EM agents should be installed with a separate user. Jobs also should be executed as a separate user so you don't need to use oracle's crontab.


On Wed, Feb 26, 2014 at 4:42 PM, Herring, David <> wrote:

> Not exactly. Both our individual accounts and "oracle" will have both
> groups (dba and oinstall). In our case the goal is to isolate shared
> accounts and track their usage. There's a side effort with this to use a
> RedHat directory server for centralizing permissions at the Linux-level but
> I'll leave that one for another day.
> In terms of setting my env, I can set all the variables I want but what
> the Linux guys are telling me is that when I "sudo" something as "oracle",
> only a bare minimum of env variables will be set. So I could have
> $ORACLE_SID, $ORACLE_HOME, $PATH, ... set to specific values but if I run
> "sudo -u oracle", the script won't have the $ORA* variables set
> and $PATH could be different, probably just whatever is set in /etc/profile.
> So based on the above and the fact I can only pass 1 command to the "sudo"
> command, I've got to figure out a way to set my env appropriate with the
> matching command I want executed as "oracle". Not all commands need to be
> run as "oracle" but I need to factor in we've got agents on every server,
> have single nodes and RACs up to 9 nodes, we've got some RACs with 2 to 6
> database spread across them, releases 9i through 11g, data guard, OGG, etc.
> Definitely EM console and Jobs will be my friend, assuming the agent
> itself won't have issues.
> Dave Herring
> From: Andy Wattenhofer []
> Sent: Wednesday, February 26, 2014 4:13 PM
> To: Herring, David;
> Subject: Re: "oracle" lockdown
> It appears to me that the changes you are facing are to enforce role
> separation, for security purposes. That is the purpose of having the two
> dba and oinstall groups created as part of the Oracle install process. It
> permits separation between the software owner (oinstall) and the database
> administrator (dba).
> If your login id is a member of the dba group, you should be able to run
> everything under your own id. In theory, you could get by without sudo
> except for patching and install operations, which require oinstall group.
> The oracle user id is a member of oinstall.
> You can source the .bash_profile from the oracle user in your own
> .bash_profile:
> . /home/oracle/.bash_profile
> (you'll probably have to adjust some file permissions before that will
> work).
> Andy
> On Wed, Feb 26, 2014 at 2:19 PM, Herring, David <> wrote:
> 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
> --
> --
> Andy Wattenhofer
> Manager, Database Administration
> University of Minnesota

Received on Thu Feb 27 2014 - 00:06:01 CET

Original text of this message