RE: "oracle" lockdown

From: Herring, David <>
Date: Thu, 27 Feb 2014 17:11:34 -0600
Message-ID: <>

Thanks Niall for sharing helpful ideas. I agree about "oraenv" and have been an advocate for using it even when there were issues with ulimit and missing "fi" in if tests. I just fixed the code, raised SRs and moved on.

The problem related to cron is, I'm told it won't be allowed for any shared account. For the most part I don't care as I've tried to force everyone to be using EM Jobs since we have agents everywhere. The biggest issue then is healthchecks of EM itself, which would only be on EM servers. Still working on that one.

Dave Herring

From: [] On Behalf Of Niall Litchfield Sent: Thursday, February 27, 2014 3:27 AM To: ORACLE-L
Subject: Fwd: "oracle" lockdown

oops - now sending to the list! 

I also forgot to mention, if this security initiative is in respect of an audit, make sure that your time/cost estimates for implementing this are realistic. You'll often find that this sort of thing is presented as a "no-brainer" to IT management and then you end up with 3-6 months of work off and on getting all your little local oddities sorted. At least if up front people know that this "simple change" will cost a lot in effort they'll pay better attention to the cost/benefit analysis. 

  • Forwarded message ---------- From: Niall Litchfield <> Date: Thu, Feb 27, 2014 at 9:23 AM Subject: Re: "oracle" lockdown To:

On Thu, Feb 27, 2014 at 5:14 AM, Jinwen Zou <> wrote: sudo is used to change the effitive uid/gid of the execute command. If you want to run the .profile/.bash_profile and change HOME enviroment variables and get interactive shell etc, you can add -i option. Please check: But in Dave's case - the post that started this the interactive shell is specifically excluded - so sudo -i will not be permitted. 

I think Dave you will *mostly* be OK. 

I expect you are aware, but oraenv is explicitly designed to be callable from a shell script - set ORAENV_ASK=NO and of course pass ORACLE_SID in and you will get the Oracle environment setup correctly.<aside> it annoys me somewhat that so many people seem to have spent so much time reinventing oraenv </aside>. As others have said membership of the dba group and/or knowledge of the sysdba password if there is one ought to get you all the access for maintenance you require. 

You are likely still going to want to setup a generic account of some description on each server to run the maintenance tasks - this might well be the user you choose to install a management agent for EM as, but if you don't use EM then you'll want *somewhere* for cron jobs etc to run. You probably also want a centralized script repository rather than a per dba repository in everyones home directory, this account would be a good owner for that. 

I'd respectfully suggest that the answer to the interactive install problem is not to do any :) , home cloning, response files and silent install of patches as well as EM deployment procedures are all likely available to you. 

Two areas I think you may have issues with that I haven't yet seen mentioned. 

  1. EM agents, you can and should set these up to run as a different user to the oracle software owner, but this isn't especially easy and I *think* some operations will require sudo access that you won't have. 
  2. trace files. These you may not get access to and trace_files_public is horrible. 

finally gmail thinks Dave's domain is untrusted and so half of this conversation was sitting in my spam folder (in case anyone else has similar issues)     


Niall Litchfield
Oracle DBA 
Received on Fri Feb 28 2014 - 00:11:34 CET

Original text of this message