Re: Looking for opinions...
- From: "Rajeev Prabhakar" <rprabha01@xxxxxxxxx>
- To: JSweetser@xxxxxxxx
- Date: Thu, 31 Jan 2008 12:58:34 -0500
Joe,
If you are worrying about someone accidentally dropping objects OR undertaking
any DDL activity given that they are connected as schema owner, it can be
surely addressed without roles/permissions. Yes, I understand ideally,
as a best
practice, administrators / designers must roll out applications which
have user ids
with appropropriate roles granted (i.e. no direct schema owner
handshake) outside
of a very strong business reason to do otherwise.
-Rajeev
On Jan 31, 2008 11:42 AM, Sweetser, Joe <JSweetser@xxxxxxxx> wrote:
> Never mind.
>
> ERROR at line 1:
> ORA-01749: you may not GRANT/REVOKE privileges to/from yourself
>
> Sheesh, joe!
>
>
> -----Original Message-----
> From: Sweetser, Joe
> Sent: Thursday, January 31, 2008 9:38 AM
> To: oracle-l@xxxxxxxxxxxxx
> 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.
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
