Re: Port Reports: UnixWare/Failure/Priviledge Test - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Port Reports: UnixWare/Failure/Priviledge Test
Date
Msg-id 20136.1067460593@sss.pgh.pa.us
Whole thread Raw
In response to Port Reports: UnixWare/Failure/Priviledge Test  (Larry Rosenman <ler@lerctr.org>)
Responses Re: Port Reports: UnixWare/Failure/Priviledge Test
List pgsql-hackers
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.

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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: 7.4 compatibility question
Next
From: Larry Rosenman
Date:
Subject: Re: Port Reports: UnixWare/Failure/Priviledge Test