Re: Port Reports: UnixWare/Failure/Priviledge Test

--On Wednesday, October 29, 2003 15:49:53 -0500 Tom Lane
<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Larry Rosenman <ler(at)lerctr(dot)org> writes:
>> --On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20
>> <tgl(at)sss(dot)pgh(dot)pa(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749