Re: Bogus permissions display in 7.4 - Mailing list pgsql-hackers

I wrote:
> If you like that, I have a further suggestion, which is to not include
> the owner's grant options in the default ACL, either.

I've been thinking more about this, and realizing that there are more
implications than I first thought.  Specifically, we have to consider
how any hacking we do here will affect recursive_revoke().  The
different options I've suggested would have different side effects,
and I'm having a hard time deciding which is better.

In the existing 7.4 code, you can revoke the owner's privileges but not
his grant options.  This confuses the ACL display code (and possibly
clients that try to interpret ACL displays), and it means that you can't
use recursive_revoke to get rid of everyone but the owner's privileges.

In my proposal of earlier today, you can revoke the owner's grant
options, which will force recursive revocation of everyone else's
privileges (since these all flow ultimately from the owner's grants).
This implies that it is not possible for the owner to have less
privileges than anyone else.  Perhaps that is not bad, but up to now it
was possible to configure a table that way.  Another problem is that
because GRANT still acts as though the owner has grant options, he can
then go and re-grant privs to other people (or the superuser can do it).
Now you have an ACL in which privileges appear to flow from the owner
despite having no grant options.  That will confuse matters --- for
example, if the owner does REVOKE GRANT OPTION FROM himself a second
time, this time it will *not* recursively kill everyone else's
privileges, because recursive_revoke will not see any need to recurse.

If we remove the owner's grant options from the default ACL then
revoking the owner's grant options won't ever recurse (unless he first
grants them to himself explicitly and then revokes them).  Perhaps
that's good?  I'm not sure.

We could patch around some of these problems if recursive_revoke knew
who the owner was (and could thereby take into account the implicit
owner grant options that I still think we want to have).  But it does
not know that, and some of its callers do not either.

Messier and messier.  I'm beginning to see why the SQL spec wants to
introduce a _SYSTEM authid to be the original source of rights.

It could be that the only good solution is to introduce knowledge of the
owner directly into the ACL representation.  You could see the spec's
approach as doing that: he who gets his rights directly from _SYSTEM
is the owner.  Another perhaps more compact way is to make a separate
ACL_IDTYPE to represent "owner" (we are using only 3 of the 4 possible
bitpatterns so this would be easy).

Comments?
        regards, tom lane