From: "Bob Beilstein" <rjbeilstein@earthlink.net>
Subject: Re: granting privileges on other user
Date: 2000/03/03
Message-ID: <LVTv4.1652$VG6.67814@newsread1.prod.itd.earthlink.net>#1/1
References: <38beb947.697559@news.remarq.com> <kilv4.38$qL4.4724@newsread1.prod.itd.earthlink.net> <89ksap$rfn$1@bcrkh13.ca.nortel.com>
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-Complaints-To: abuse@earthlink.net
X-Trace: newsread1.prod.itd.earthlink.net 952109803 168.191.60.45 (Fri, 03 Mar 2000 10:56:43 PST)
Organization: Manugistics, Inc.
X-MSMail-Priority: Normal
Reply-To: "Bob Beilstein" <rjb@manu.com>
NNTP-Posting-Date: Fri, 03 Mar 2000 10:56:43 PST
Newsgroups: comp.databases.oracle.server


Yep, I did know that (have done that...).

If this was an operational requirement, that's exactly how I would go about
implementing it -- but the question was not "how do I do this", but rather
"how does it work"...

On the other hand, I agree that my comment could have been taken as "you
can't to that", so I appreciate the clarification.

        / Bob

"John" <johnbagnell@hotmail.com> wrote in message
news:89ksap$rfn$1@bcrkh13.ca.nortel.com...
> Of course you (as the DBA) can still change the user's password, perform
> whatever grants you wish on their objects, then change the password back.
 The
> user really can't control this.
>
> Using SELECT username, password FROM dba_users;  (and saving the encrypted
> password)
> ALTER USER username IDENTIFIED BY passwd;
>
> {Then connecting as that user and performing your grants}
>
> Then:
>
> ALTER USER username IDENTIFIED BY VALUES
> 'theencryptedpasswordstringyousavedfromtheearlierquery';
>
> You can assume a user's identity and do whatever you like, without ever
 knowing
> the user's password.
>
>
>
>
>
> Bob Beilstein wrote:
>
> > <<stuff>>
> >
> > Basically, the idea is that while a user cannot prevent a DBA (or a user
> > with SELECT ANY TABLE role) from seeing the data in his/her tables (or a
> > user with UPDATE ANY TABLE from changing it, etc.), (s)he still retains
> > control over granting privileges to "ordinary mortals" unless (s)he
> > specifically decides to allow another user to do so.
> >
> >
>
>