I am implementing the grant option feature which enables an object owner
to allows others to re-grant privileges. For REVOKE you can specify
CASCADE and privileges granted in this manner are revoked recursively.
Currently, I have made it so that you can only give grant options to
users, not groups. The problem is that when a user has granted privileges
having had the grant option through a group and is later removed from the
group then the privileges should be revoked, but the old problem is that
it's not possible to do this in all databases.
I have extended the aclitem external format as follows:
grantee=a*bc*/grantor
means the "a" and "c" privileges are held with grant option (the letters
are just examples), and the whole thing was granted by the given grantor.
(You can hold the same privilege many times granted by different users.)
What are the requirements for backward compatibility here? If the "*" are
missing then the privilege is held without grant option which is currently
the default. If the "/grantor" portion is missing then it's assumed to be
equivalent to the grantee. This makes sense in a limited number of cases.
One would like to have the object owner as the default but the
"aclitemout" function doesn't have information about that.
I noted three undocumented SQL function operating on ACLs: aclinsert,
aclremove, aclcontains. What are those intended for? How should they
maintain the integrity of the ACL that is ensured by cascading revoke?
In order to query the availability of a grant option I would like to
extend the has_foo_privilege family of functions so that they can take as
the privilege type argument, say, 'UPDATE WITH GRANT OPTION' instead of
'UPDATE'. In order to be able to represent the grantee/grantor
relationship in the information schema I also need a function
has_foo_privilege_granted_by(grantee, objectid, priv, grantor).
Comments?
--
Peter Eisentraut peter_e@gmx.net
