RE: User equiv and "oracle" lockdown
- From: "Herring, David" <HerringD@xxxxxxx>
- To: Niall Litchfield <niall.litchfield@xxxxxxxxx>
- Date: Tue, 23 Sep 2014 12:01:14 -0500
Niall, I agree but unfortunately quotes and links to the installation guide
aren't enough for the security team. In this specific case the issue was with
generating keys manually up front and doing so for a different user. In 10g
the doc shows just generating as "oracle", for "oracle" and ssh'ing to build
the full authorized_keys set. In 11g the installer tries to do this for you
and to do that it asks for Oracle's password. That's where the trouble began.
My struggle with this is I'm getting bits and pieces on what the rules are,
nothing pre-defined which would allow me to plan and test. I think it was
Matthew yesterday pointed this out by asking what compliance rules are they
following. I'm trying to force this answer through management since I'm not
getting anything from the security team.
To this issue, I generated keys as "oracle" for each node, copied them back and
force making sure to concatenate the results into a full set. It's a bit
different from the doc especially since the key generation commands and
placement of authorized_keys are all needing a "sudo -u oracle" prefix, then
scp'ed as me across the nodes.
Dave Herring
From: Niall Litchfield [mailto:niall.litchfield@xxxxxxxxx]
Sent: Tuesday, September 23, 2014 2:27 AM
To: Herring, David
Cc: ORACLE-L
Subject: Re: User equiv and "oracle" lockdown
I guess I'm struggling to understand what the issue is here. User equivalence
or passwordless ssh is required for a supported installation. Arguing about
what may or may not break is surely beside the point.
On 22 Sep 2014 20:29, "Herring, David" <HerringD@xxxxxxx> wrote:
Does anyone know all areas where user equivalency for the account "oracle" is
necessary in a RAC system, let's say 11g and above on Linux RH?
The reason I ask is that our security team is now refusing to have this set up
and even though I passed snipets from Oracle doc which states "it must be set",
they're balking and sending snipets from RedHat doc saying that's unwise.
Without user equiv for "oracle" I believe the following will break/have issues:
* Proper management agent monitoring. The agent needs to know it's a RAC to
properly monitor the configuration. I don't have specific examples, just
oddity with agent behavior when user equiv isn't set properly.
* All "cluvfy" uses will fail. Most are interactive uses but the management
agent uses it too for cluster verification. So in a way almost all our ability
to validate the cluster will be unavailable.
* All installs, patches, upgrades will fail or least be a complete hack.
Rolling patch application would never be possible, I assume.
I know the cluster will still work without user equiv as I've run into enough
existing systems where the DBA didn't do it properly or didn't properly add new
nodes. Is there anything else that would break/be a major pain? Since
documentation proof isn't enough I need to explain in (my) painful detail of
why we need it.
Dave Herring
--
//www.freelists.org/webpage/oracle-l
Other related posts:
