Re: Port Reports: UnixWare/Failure/Priviledge Test

--On Wednesday, October 29, 2003 15:49:53 -0500 Tom Lane
<tgl@sss.pgh.pa.us> wrote:

> Larry Rosenman <ler@lerctr.org> writes:
>> --On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20
>> <tgl@sss.pgh.pa.us> wrote:
>> [snip]
>>> Is this a bug, or is it correct-per-spec behavior?  It's surely likely
>>> to confuse people.  I wonder whether superusers shouldn't be allowed to
>>> revoke privileges granted by other people.  As the code stands, they
>>> cannot.
>
>> It seems to me that a superuser SHOULD be able to affect ANY permissions
>> on ANY object in the DB.
>
> Well, of course a superuser can do SET SESSION AUTHORIZATION to "become"
> the other person, and then execute GRANT or REVOKE commands to update
> the permissions as he wishes.  This seems reasonable for the GRANT case
> (otherwise we'd need to add a clause to GRANT to specify which userid to
> grant the permissions as).  For REVOKE, though, I'm wondering if a
> superuser-issued REVOKE shouldn't revoke the specified permissions
> regardless of who granted them.
I like this idea....
>
> An alternative, possibly cleaner approach is that a superuser-issued
> GRANT or REVOKE should be executed as though it were issued by the
> object owner.  This would mean that all privileges ultimately flow from
> the object owner, which seems reasonable intuitively.  Right now, you
> can have a situation where some privileges on an object are granted by
> the owner and some are granted by various random superusers.  Not sure
> that that is a good idea.
I like this even better.  I don't like the fact that right now some
superusers are different from other superusers.

IMO, of course....

--
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749