dmg@uvic.ca writes:
> I am trying to understand how postgresql implements REVOKE GRANT ...
> CASCADE
> [ example snipped ]
> What I am surprised is that m keeps the proviledge (via b) but x and y have
> lost it. See below). is that the way it is supposed to be?
It is not. There is actually code in there that is supposed to deal
with this consideration, but it's got a trivial bug :-(. Will fix,
and add a regression test example too. Thanks for the report!
regards, tom lane
diff --git a/src/backend/utils/adt/acl.c b/src/backend/utils/adt/acl.c
index 77322a115f1f7b36e08541ae6ab5e3fd873aea5b..cf04c420d9808a46828783489536932cc3530f05 100644
*** a/src/backend/utils/adt/acl.c
--- b/src/backend/utils/adt/acl.c
*************** recursive_revoke(Acl *acl,
*** 1230,1240 ****
if (grantee == ownerId)
return acl;
! /* The grantee might still have the privileges via another grantor */
still_has = aclmask(acl, grantee, ownerId,
ACL_GRANT_OPTION_FOR(revoke_privs),
ACLMASK_ALL);
! revoke_privs &= ~still_has;
if (revoke_privs == ACL_NO_RIGHTS)
return acl;
--- 1230,1240 ----
if (grantee == ownerId)
return acl;
! /* The grantee might still have the grant options via another grantor */
still_has = aclmask(acl, grantee, ownerId,
ACL_GRANT_OPTION_FOR(revoke_privs),
ACLMASK_ALL);
! revoke_privs &= ~ACL_OPTION_TO_PRIVS(still_has);
if (revoke_privs == ACL_NO_RIGHTS)
return acl;