RE: "oracle" lockdown
- From: "Herring, David" <HerringD@xxxxxxx>
- To: "niall.litchfield@xxxxxxxxx" <niall.litchfield@xxxxxxxxx>, ORACLE-L <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 27 Feb 2014 17:11:34 -0600
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: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] 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 <niall.litchfield@xxxxxxxxx>
Date: Thu, Feb 27, 2014 at 9:23 AM
Subject: Re: "oracle" lockdown
To: zjworacle@xxxxxxxxx
On Thu, Feb 27, 2014 at 5:14 AM, Jinwen Zou <zjworacle@xxxxxxxxx> 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:
http://www.gsp.com/cgi-bin/man.cgi?topic=sudo
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
http://www.orawin.info
--
//www.freelists.org/webpage/oracle-l
Other related posts:
