Xref: alice comp.databases.oracle.misc:35493 comp.databases.oracle.server:56294
Path: alice!news-feed.fnsi.net!newspump.monmouth.com!newspeer.monmouth.com!logbridge.uoregon.edu!nntp2.deja.com!nnrp1.deja.com!not-for-mail
From: roguedood@my-deja.com
Newsgroups: comp.databases.oracle.server,comp.databases.oracle.misc
Subject: Re: Pros vs Cons of 'With Admin Option'
Date: Wed, 07 Jul 1999 06:48:08 GMT
Organization: Deja.com - Share what you know. Learn what you don't.
Lines: 96
Message-ID: <7lut76$4hf$1@nnrp1.deja.com>
References: <7ltmtr$nhb$1@nnrp1.deja.com> <7lumcm$tl$1@autumn.news.rcn.net>
X-Article-Creation-Date: Wed Jul 07 06:48:08 1999 GMT
X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; MSN 2.5; Windows 98; DigExt)
X-Http-Proxy: 1.1 x33.deja.com:80 (Squid/1.1.22) for client 24.28.43.158

http://govt.us.oracle.com/~tkyte

- Sean

In article <7lumcm$tl$1@autumn.news.rcn.net>,
  "Jerry Gitomer" <jgitomer@erols.com> wrote:
> Hi,
>
>     If you can go to Oracle 8i you can find the answer to your
> problem on Thomas Kyte's website.  (I am not sure, but I think
> the URL is
> us.govt.oracle.com/~tkyte -- if this is not it will someone
> please provide the correct address)  Look at his articles for one
> addressing the issue of "Fine Grained Access".
>
> regards
> Jerry Gitomer
> -----------------------------------------
>
> rspeaker@my-deja.com wrote in message
> <7ltmtr$nhb$1@nnrp1.deja.com>...
> >Okay gang, I need some advice.
> >
> >I am DBA'ing a system that currently has about 5 developers.  As
> part
> >of the initial setup, I created a pseudo-admin user called ADM,
> and
> >through the use of roles, gave the ADM account the ability to
> create
> >other users and grant permissions to those users, such as create
> table,
> >create sequence, etc.
> >
> >Up to this point it has worked out well.  With the ADM account
> having
> >the 'ADMIN OPTION' for creating tables, etc, the developers have
> been
> >able to create users, as well as 'schema-owner IDs'.  However,
> they are
> >now requesting that the ADM user be given 'CREATE ANY xxx'
> privileges
> >'WITH ADMIN OPTION', and I'm torn about this.  In my opinion,
> giving
> >ANY non-DBA user ID the ability to CREATE ANY xxx in ANY other
> users's
> >schema creates a convoluted environment.
> >
> >Their arguments consist of 2 points:
> >
> >(1) having a "super" user allows them to develop in any schema
> at any
> >time without having to switch user IDs.  It makes their script
> creation
> >and running simpler.  My reply to that is that it only takes 1/2
> second
> >to issue a connect user/pass statement to develop in a different
> schema.
> >
> >(2) they want to be able to audit what developer is doing what,
> and
> >when.  Good point here.  I know we can enable auditing at the
> database
> >level, but if the developers are connecting as the schema-owner
> to do
> >their work, I don't know of any way to correlate this back to an
> >external user.  SYS.AUD$ contains a username and userhost field,
> and
> >even if that can somehow be tied to V$SESSION to pick up on the
> >username and hostname of the PC connecting to the database, that
> >doesn't do me any good if DeveloperB sits down at DeveloperA's
> PC and
> >logs on.
> >
> >Need your advice folks....how have you handled similar requests
> /
> >situations ?  On the one hand I understand their desire to be
> able to
> >audit the development work, but on the other hand, shouldn't
> they trust
> >each other?  And I still see the granting of CREATE ANY to a
> non-DBA
> >user ID as opening the door to polluting the environment.
> >
> >Thoughts / comments readily welcomed ....
> >
> >Thanks.
> >
> >
> >Sent via Deja.com http://www.deja.com/
> >Share what you know. Learn what you don't.
>
>


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.