Re: DBAs running root.sh
Date: Mon, 3 Feb 2014 15:58:25 -0200
Message-ID: <CAJ2dSGS8QfKCF0+nLxRv06TuSY0o+R9b2YM02T+NTXCS21xbsQ_at_mail.gmail.com>
I've bumped into this problem in many envirnoments. They key here, I think, is that the RDBMS servers are dedicated. In this scenario, and especially if you are running 11.2 RAC, I believe the correct approach is to have the DBA as owner of the root password on the system and have the SA team as a technical escalation (a center of expertise of sorts) for tasks the DBA is not able to complete. As a DBA I am NOT OK with someone who is not a DBA having root access to the system as that grants them SYSDBA access to the databases for which I am responsible. This required the DBA team to have their own SA expert or at the very least that some DBAs have well developed OS skills. I think most of the top notch DBAs out there already do, as knowing the OS is essential for proper sizing, tuning and general maintenance as well as the base for any informed decision when choosing a platform.
If you have a very large environment, with standardized installation
practices, then it would be trivial to implement one of the following
solutions:
A: Hybrid DBA/SA involvement
1. DBA performs the install (silent install without configuration for GI
and silent install for RDBMS)
2. SA runs the root.sh from their own machine (they may need to be trained
to resolve GI root.sh issues)
3. SA takes care of GI management (again, extensive training is required
for this)
4. DBA takes care ONLY of ASM and the Databases
B: SA installs everything
1. SA performs the install (either silent or GUI) and runs root.sh 2. SA still takes care of GI management 3. DBA takes care of ASM and DBs
I've often found that when I suggest the second approach, they end up giving me root in the environment, as SAs typically don't want (or have the time) to learn how to patch an $OH (especially considering the complexities added when applying CPU/PSUs). This is basically saying "so, you don't want to give me the tools I need to do my job? that's ok, then you go ahead and do it yourself"
the root.sh script is owned by the 'oracle' user ($OH owner), so adding it to sudo is almost the same as granting sudo for everything to the oracle user. As far as I know, when you add an executable to the sudo list, you can run it as root, that means that whatever is inside the executable (in this case a script) will be run as if it were run by root and NOT subjected to any more rules. So it would be just a matter of editing the root.sh script (which as the oracle user we can do) and then we could run *anything* as root, even visudo.
You *could* deploy a modified version of root.sh which executes the sudo calls inside, and add the actual executables the root.sh needs, thus preventing the scenario depicted above. However this would require a lot of effort and extensive testing as well as a new version for each patchset, and this would almost certainly not be supported by Oracle.
hth
cheers
Alan.-
PS: if the RDBMS servers are not dedicated, I suggest you point out the risk of not having dedicated RDBMS servers first :-P
Alan.-
On Mon, Feb 3, 2014 at 2:08 PM, Austin Hackett <hacketta_57_at_me.com> 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
>
>
>
>
>
>
> --
> http://www.freelists.org/webpage/oracle-l
>
>
>
-- http://www.freelists.org/webpage/oracle-lReceived on Mon Feb 03 2014 - 18:58:25 CET