--On Wednesday, October 29, 2003 15:49:53 -0500 Tom Lane <[EMAIL PROTECTED]> wrote:
Larry Rosenman <[EMAIL PROTECTED]> writes:I like this idea....--On Wednesday, October 29, 2003 15:26:39 -0500 Tom Lane=20 <[EMAIL PROTECTED]> 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 even better. I don't like the fact that right now some superusers are different from other superusers.
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.
IMO, of course....
-- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
pgp00000.pgp
Description: PGP signature
