From oracle-l-bounce@freelists.org Mon Oct 24 13:43:44 2005 Return-Path: Received: from air891.startdedicated.com (root@localhost) by orafaq.com (8.12.10/8.12.10) with ESMTP id j9OIhiCf029573 for ; Mon, 24 Oct 2005 13:43:44 -0500 X-ClientAddr: 206.53.239.180 Received: from turing.freelists.org (freelists-180.iquest.net [206.53.239.180]) by air891.startdedicated.com (8.12.10/8.12.10) with ESMTP id j9OIhevX029540 for ; Mon, 24 Oct 2005 13:43:40 -0500 Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id CE10C20D851; Mon, 24 Oct 2005 13:43:37 -0500 (EST) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15448-05; Mon, 24 Oct 2005 13:43:37 -0500 (EST) Received: from turing (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 4F2EB20D862; Mon, 24 Oct 2005 13:43:37 -0500 (EST) From: "Henry Poras" To: Subject: PCI compliance and shared Linux accounts Date: Mon, 24 Oct 2005 14:44:51 -0400 Message-ID: <006c01c5d8cb$04ab67f0$3800040a@itasoftware.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006D_01C5D8A9.7D99C7F0" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-archive-position: 27469 X-ecartis-version: Ecartis v1.0.0 Sender: oracle-l-bounce@freelists.org Errors-To: oracle-l-bounce@freelists.org X-original-sender: henry@itasoftware.com Precedence: normal Reply-To: henry@itasoftware.com X-list: oracle-l X-Virus-Scanned: by amavisd-new-20030616-p9 (Debian) at avenirtech.net X-mailscan-MailScanner-Information: Please contact the ISP for more information X-mailscan-MailScanner: Found to be clean X-MailScanner-From: oracle-l-bounce@freelists.org X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on air891.startdedicated.com X-Spam-Level: X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.63 ------=_NextPart_000_006D_01C5D8A9.7D99C7F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ------=_NextPart_000_006D_01C5D8A9.7D99C7F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable PCI compliance and shared Linux accounts

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

------=_NextPart_000_006D_01C5D8A9.7D99C7F0-- -- http://www.freelists.org/webpage/oracle-l