Oracle lockdown, agents, and EM Jobs

From: Herring, David <HerringD_at_DNB.com>
Date: Wed, 18 Jun 2014 17:07:53 -0500
Message-ID: <AD8FE6616C097545A4C9A8B0792909AC38383FDF35_at_DNBEXCH01.dnbint.net>



Folks,

As some of you may recall I've been placed in a situation where we need to lock down all access of "oracle" at the OS level, have hundreds of existing installs where GI, Oracle, and the management agent are installed as "oracle" (RAC, non-RAC + 10g, 11g), along with many custom EM Jobs for DBA maint and monitoring.

What I've run into is a bit of a complexity in dealing with OS environment, the agent, and EM Jobs. I thought I'd try to post the whole situation here since I have a tendency to make things overly complex and I may be missing something obvious (as the old programmer saying goes, if it was hard to write it should be hard to understand).

<setup>

1) User "oracle" has no direct login or shell available. All commands to run as "oracle" must be run under our individual accounts prefixed with "sudo -u oracle".

2) Only 1 command can be run at a time as "oracle" (no shell).

3) Cron access is gone, so anything we want scheduled must be from EM.

4) Periodically DBAs have to restart/fix agent issues, so they restart the agent using something like "sudo -u oracle $AGENT_HOME/bin/emctl start agent". The agent now runs as "oracle" yet has all it's environment inherited from the DBA who ran the command.

5) We have 50 or so maint/monitoring scripts stored either on a NAS or locally. In both cases they follow the same directory structure but the mount may have a different name. To get around this all .bash_profile scripts for "oracle" set a variable for the mount, like "MNT". Therefore regardless of shared or local the scripts would always be found under $MNT/... This also means the scripts can't be found by "oracle" unless .bash_profile is first sourced.

6) We have 12 DBAs on our team with accounts managed by a RedHat LDAP server. The DBAs are in charge of x number of environments, with "x" depending on complexity and what the given DBA can handle. DBA shifts cover 24/5 with oncall the other 2.
</setup>

Lets say I have maintenance script $MNT/admin/shell/x.sh. Creating this as an EM Job (EMJ) I need OS credentials and I also need to make sure $MNT is known. So I make the command line of the Job ". ~/.bash_profile; sudo -u oracle $MNT/admin/shell/x.sh". Since all DBA accounts are basically the same it doesn't matter whose credentials are used so lets say Mark's account is used. Lets also say that earlier the agent on this server had an issue and Tim, working a different shift than Mark, fixed the problem and restarted the agent.

The agent runs as "oracle" but it's environment is all set off Tim's account. Now EM Job "EMJ" fires off and users Mark's credentials, so as "markb" it tries to run /user/timg/.bash_profile. Why under "/user/timg"? Because $HOME=/user/timg, since Tim restarted the agent.

Lost interest yet? I have a few options on how to fix this but before I try I figured I better check with more folks as again, I want to avoid making this more complex than it has to. I'll reply to this with options as I see them in case the 1 or 2 people still reading this are interested.

Dave Herring

--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jun 19 2014 - 00:07:53 CEST

Original text of this message