Re: User equiv and "oracle" lockdown

  • From: "Radoulov, Dimitre" <cichomitiko@xxxxxxxxx>
  • To: oracle-l@xxxxxxxxxxxxx
  • Date: Tue, 23 Sep 2014 10:09:52 +0200


On 23/09/2014 09:27, Niall Litchfield wrote:

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.


I completely agree with Niall. In my opinion, if the software vendor is asking you to do something and the security team disagrees,
they should ask the vendor (Oracle), not you, to fix it.

On 22 Sep 2014 20:29, "Herring, David" <HerringD@xxxxxxx <mailto: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.


I'm sure that opatch uses ssh to verify the inventory on the remote nodes for all the software (EM agents, GI and DB).

    * 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.


From 11.2.0.2 onward, cluvfy runs at a regular basis (i.e. non interactive usage),check the schedule with srvctl config cvu. I suppose that it will fill your GI alert log with errors, if you deconfigure ssh passwordless access.

    * 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: