Re: BUG #3319: Superuser can't revoke grants on a schema given by aother user

On 05/30/2007 07:55:58 PM, Tom Lane wrote:

> Pedro Gimeno Fortea <pgsql@personal.formauri.es> writes:
>=20
> > Still, is silently ignoring the command the proper action to take
> > when the REVOKE is executed by the superuser and not by the
> > grantor?
>=20
> You want a warning when REVOKE didn't do anything because there was=20=20
> no prior grant to be revoked?

No, I want a warning when REVOKE didn't do anything because there *was*=20=
=20
a grant to be revoked, but the user who wanted to revoke it was not the=20=
=20
grantor.

Actually I'd rather prefer the REVOKE to be effective when the user who=20=
=20
wants to do it is a superuser; otherwise at a minimum a NOTICE-level=20=20
message would be desirable. If that is "too noisy", then I guess that=20=20
other NOTICEs are too and the DBA should disable notices. I really=20=20
think that this kind of notification is more important than e.g. the=20=20
implicit creation of a primary-key index, because of the security=20=20
implications (the superuser may think that the permission is revoked=20=20
when it actually isn't, so the grantee can do Bad Things).

Note that this is not similar to the GRANT case. I'd say it's similar=20=20
to wanting to delete a table created by another user: if you're not the=20=
=20
owner, you can't, unless you're a superuser. The similarity becomes=20=20
obvious when replacing "delete a table created by" with "revoke a=20=20
privilege granted by" and "owner" by "grantor".

At the very least, if nothing is changed then this quirk should be=20=20
documented, perhaps in the REVOKE statement.

> According to the code comments, this was considered and rejected as=20=20
> "too noisy, as well as inconsistent with the GRANT case".  I can't=20=20
> find the discussion right now, but it would have probably been in May=20=
=20
> 2004 or a bit before, because the comment seems to date from a commit=20=
=20
> on 1 June 2004.

In a situation as you state it (the destination user doesn't have that=20=
=20
privilege on the object at all), I would agree, but the scenario I'm=20=20
stating is different.