Re: PCI compliance and shared Linux accounts

  • From: Rodd Holman <Rodd.Holman@xxxxxxxxx>
  • To: henry@xxxxxxxxxxxxxxx
  • Date: Mon, 24 Oct 2005 14:10:05 -0500

Henry, can you sudo vi runInstaller.sh and add a line to the top of the shell DISPLAY=yourlocalXdisplay:0 and export DISPLAY
That should allow the sudo command to work through the ssh X tunnel.


Rodd

Henry Poras wrote:

Rodd,
The problem is I would ssh -X henry and then sudu su - oracle (need to sudo
and not su since I don't know the 'oracle' password). It's at the su when X
is dropped.


Henry


-----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Rodd Holman Sent: Monday, October 24, 2005 2:50 PM To: oracle-l@xxxxxxxxxxxxx Subject: Re: PCI compliance and shared Linux accounts


Henry,
You don't need a direct connect as Oracle. Just ssh -X and it will tunnel the X stuff back to your display. Just export the display back. If you need to do it as a sudo rather than su - oracle, write a wrapper shell for runInstaller.sh that exports the display to your display and then run it.


Rodd

Henry Poras wrote:



I am wondering how other companies deal with this issue. We are currently enmeshed in the PCI (payment card industry) compliance process. One of the requirements is "do not permit group, shared, or generic accounts/passwords." This means that when we need to access the database server, we will connect as ourselves, and then sudo to the 'oracle' account. For a single node database (non-RAC) this doesn't seem like a big deal. The only limitation is the necessity of a direct connect for X-windows implementation. If we want to avoid a silent install we will need a direct login as 'oracle', but OUI isn't used too frequently.

I was wondering more about the problems we will have with RAC. An 'oracle' password will again be necessary for X, as well as to configure scp in the installation process. There are also some other tasks that will be more difficult. For example, running the monitoring tool RACDDT (it will destroy your environment as it removes the bugs???) uses ssh. I guess I could run it from my personal account if I am careful to set all permissions, but ...

I guess I am wondering how important having direct access to a shared 'oracle' account will be in a RAC environment. Are there any emergencies or administrative tasks that will become noticably more difficult with this limitation in place?

Thanks.

Henry









--
Rodd Holman
Enterprise Data Systems Engineer
LodgeNet Entertainment Corporation
rodd.holman@xxxxxxxxx

--
//www.freelists.org/webpage/oracle-l

Other related posts: