Re: DBAs running

From: Guillermo Alan Bort <>
Date: Mon, 3 Feb 2014 15:58:25 -0200
Message-ID: <>

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 from their own machine (they may need to be trained to resolve GI 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
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 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 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 which executes the sudo calls inside, and add the actual executables the 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.


PS: if the RDBMS servers are not dedicated, I suggest you point out the risk of not having dedicated RDBMS servers first :-P


On Mon, Feb 3, 2014 at 2:08 PM, Austin Hackett <> wrote:

> Hi List
> If you work in a security conscious environment, I'd be keen to hear how
> your site handles the script.
> To give you some background:
> In my environment, DBAs are currently given direct root access to allow
> them to run 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 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 as the root user via sudo. This,
> of course, means that DBAs can run anything they like by editing,
> 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
> 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 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 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
> --

Received on Mon Feb 03 2014 - 18:58:25 CET

Original text of this message