Re: Oracle lockdown, agents, and EM Jobs
Date: Wed, 18 Jun 2014 20:47:11 -0500
Message-ID: <CAEueRAVM64g5CyPOuLJ5ox7CoTKnMdRmnu7YhCBTxENSzd9A_Q_at_mail.gmail.com>
David,
Kudos to your organization for taking this on. I hope you will share this experience with the community through blogs and presentations. I could see these topics easily being accepted as a presentation at any of the conferences.
With the exception of a very few (and by very few I mean less than five) situations, there should not be any scripts that need to run as oracle. I am including the EM agent as one of those things that does not require oracle. Those few things that are required to be run as oracle should be done through sudo. If executing something using sudo is leaving environment variables in place that shouldn't be there, then sudo is not set up properly.
Your messages were quite complex but you are asking very good questions here. I suggest you break it down into one or two issues per post and hash them out before moving to the next issues.
Tony,
You're quite right that jobs that need to persist across employees should never be run with credentials of an individual. Jobs should be run under a common system user. As long as no one can use this user for anything other than jobs (no local access to the servers), security would not be an issue since authorization and auditing is taken care of with EM. If separation of duties is the issue, each individual could have their own system user that could just be reassigned to someone else if necessary.
Seth
On Wed, Jun 18, 2014 at 7:59 PM, De DBA <dedba_at_tpg.com.au> wrote:
> This is becoming a very interesting story indeed. How about putting the
> common oracle environment in a file in a common location, e.g.
> /var/opt/oracle/oraenv.sh, and having each script and perhaps
> .bashrc/.bash_profile source that as appropriate? Access to this directory
> should already be allowed. We tend to do this, even where security is not
> as overzealous as what you're facing. It just makes managing environments
> more easy when everything is in one common location, whilst allowing DBAs
> to choose whether to use the common environment or not.
>
> I wonder how you are going to set up EM jobs that need os logon
> credentials. If you use a DBA's credentials, then those jobs will start to
> fail when the DBA in question leaves the organisation and his account gets
> disabled or removed from the directory.. Could be an administrative
> nightmare waiting to happen?
>
> Cheers,
> Tony
>
>
> On 19/06/14 08:18, Herring, David wrote:
>
>> Options:
>>
>> 1) Every DBA has their own .bash_profile created as a copy of Oracle's.
>> This is what I started with thinking it was simple but after one week I've
>> found 2 examples where DBAs didn't bother to follow this rule. I can't
>> control them and have no authority to force them to do anything other than
>> the bare minimum of their job.
>>
>> 2) Open permissions on /user/oracle (710) and /user/oracle/.bash_profile
>> (750) so that each EM Job could issue at the start: ".
>> ~oracle/.bash_profile". So whether daveh or markb or timg have their
>> credentials set for the target, all can execute Oracle's .bash_profile and
>> we're fine.
>>
>> Everything else I've come up with is a variation on the above 2 options,
>> either modifying DBA .bash_profiles in some way or something within
>> Oracle's home directory that requires permissions to be relaxed a bit.
>>
>> Does this make sense?
>>
>> Am I making this overly complex?
>>
>> Anyone else in a similar situation and have a better solution?
>>
>> Dave Herring
>> --
>> http://www.freelists.org/webpage/oracle-l
>>
>>
>>
>>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Thu Jun 19 2014 - 03:47:11 CEST