RE: Looking for opinions...
Date: Thu, 31 Jan 2008 12:10:55 -0500
Message-ID: <21469B88E0EA11498818517F2103353101C65E0C@EPRI17P32001A.csfb.cs-group.com>
Even though you answered your own question, let me just weigh in here.
Unless "valid business reasons" include the ability to execute DDL in
the schema, there's nothing that you can't accomplish by granting
privileges to distinct users and/or roles. In general it's considered
bad practice for applications and non-DBA uses to connect as a schema
owner.
Paul Baumgartel
CREDIT SUISSE
Information Technology
Prime Services Databases Americas
One Madison Avenue
New York, NY 10010
USA
Phone 212.538.1143
paul.baumgartel_at_credit-suisse.com
www.credit-suisse.com
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Sweetser, Joe
Sent: Thursday, January 31, 2008 11:38 AM
To: oracle-l_at_freelists.org
Subject: Looking for opinions...
Situation is a "generic" database account that too many people know the password to. But they need to know the password for valid business reasons. Does it make more sense to limit that account's access to its' own tables or create a new account(s) and grant those the specific access they need? I like the second option for various reasons (auditability (is that a word?) and accountability to name two) but others think just controlling the generic account's access to objects is fine. To be a little more clear (and one reason why I don't like the first option), there would be different privs on different tables - select only on table A; select, insert on table B; select, update on Table C; etc). Even with using roles, something just sort of bugs me about an owner/account not being to update its' own data (read-only situation exceptions, of course).
Opinions/comments/suggestions? Feel free to send back-channel and I will summarize since I don't think this falls under a technical umbrella. :-)
Thanks,
-joe
Confidentiality Note: This message contains information that may be confidential and/or privileged. If you are not the intended recipient, you should not use, copy, disclose, distribute or take any action based on this message. If you have received this message in error, please advise the sender immediately by reply email and delete this message. Although ICAT Managers, LLC scans e-mail and attachments for viruses, it does not guarantee that either are virus-free and accepts no liability for any damage sustained as a result of viruses. Thank you.
--
http://www.freelists.org/webpage/oracle-l
Please access the attached hyperlink for an important electronic communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
--
http://www.freelists.org/webpage/oracle-l
Received on Thu Jan 31 2008 - 11:10:55 CST