Re: DBAs running root.sh
- From: Ram Srinivasan <srinivasanram2004@xxxxxxxxx>
- To: hacketta_57@xxxxxx
- Date: Tue, 4 Feb 2014 09:27:07 -0500
All:
This situation occurred exactly 2 years ago at my place. Let me explain
this.
One new SA took over as SA Team Lead, and she wanted to show off her
powers. So one day, without telling anyone, she revoked the root access to
all the DBAs in one swoop. The next day I was installing some PSU patch,
and in order to run the root103.sh, I logged in to root, and it kicked me
out. When I asked the SAs, she said that root access has been revoked from
the DBAs, and from now on DBAs have to call the SAs to run the root.sh
scripts. Usually, running the root.sh script by the SAs at our place
takes hours if not days. Without consulting anyone, she took this
arbitrary decision. That is it. This infuriated me as the DBA Team Lead.
I complained to the senior management, and after 3-4 meetings and
arguments and counter-arguments, it was decided that DBAs will get the
"sudo /bin/bash" root priv. Thus the DBAs can sudo /bin/bash and go to
root, and run any script they want, and get out.
In my opinion, the DBAs should have access to root, and at the same time
DBAs should not misuse this power by changing the kernel parameters, and
other system parameters without consulting the SAs.
Thanks
Ram Srinivasan
--------------------
On Mon, Feb 3, 2014 at 12:08 PM, Austin Hackett <hacketta_57@xxxxxx> wrote:
> Hi List
>
> If you work in a security conscious environment, I'd be keen to hear how
> your site handles the root.sh script.
>
> To give you some background:
>
> In my environment, DBAs are currently given direct root access to allow
> them to run root.sh. However, the SA Team would like to tighten this up. If
> giving the DBAs direct root access isn't acceptable (not even temporarily)
> then two options spring to my mind:
>
> 1) SA team run root.sh on behalf of the DBAs. Geography and logistics in
> my organisation are such that having an SA walk over to the DBAs desk is a
> realistic option. Our SAs aren't keen on this approach
> 2) Give DBAs the ability to run root.sh as the root user via sudo. This,
> of course, means that DBAs can run anything they like by editing root.sh,
> so doesn't really help. Understandably our SAs don't like this approach
>
> I am being asked to look into keeping Oracle software version specific
> root.sh scripts in a root-owned location (we are Linux only, so no
> multi-platform concerns). This would allow for secure sudo privileges. We'd
> need these for RDBMS, Grid Infrastructure, and Client.
>
> However, I've explained the scripts are dynamically generated by
> runInstaller and have the Oracle Home path hard-coded into them. We'd need
> a root-owned root.sh for every distinct ORACLE_HOME path we create (some
> hosts have multiple homes, so there's dbhome_1, dbhome_2 etc.). Maybe there
> are other considerations that I'm unaware of - I don't really like to
> second guess what else is going on in the "closed box" of the OUI that
> could be host dependent.
>
> To my mind, taking this non-standard approach is more risky than having
> someone run the script on our behalf, even if it risks introducing delays
> into the build process.
>
> How is this handled in your organisation? Have you ever been asked to have
> a centralised set of root.sh scripts under root control for this reason?
> Have you made it work?
>
> If anyone has some time to share their experiences, it would be much
> appreciated.
>
> Regards
>
> Austin
>
>
>
>
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
Sincerely
Ram Srinivasan
Other related posts:
