Dear Tom,
> > Due to how ACL are defined in SQL, I restate my suggestion that the super
> > user should be able to change ANY right, including the GRANTOR field,
>
> I'm unconvinced of this: that philosophy soon leads you into allowing
> the superuser to create self-inconsistent sets of rights, such as rights
> [...]
I understand that you want to keep the acl state always consistent, so as
to simplify access checks that can rely on the acl to be consistent, and
to avoid some transitive closure or whatever while checking some access.
That is reasonnable enough, for performance.
However there is no necessary contradiction, as a "with grantor" can be
interpreted in two ways:
(1) execute the grant/revoke with the specified id.
(2) include this acl whatever the consistency.
Under interpretation (1), this is just a short hand for a set session
authorization xxx ; revoke/grant ; back to initial;
Now you might argue that the convinience is not necessarily needed, as the
su can set the session authorization as it wishes (I guess). From my
little practice, it would not look that bad to have such a simple and
quick syntax for such tasks.
Moreover, ROLES have such a limited "WITH GRANTOR" syntax, so the
parser may need it anyway someday.
> It's worth pointing out also that the superuser can always brute-force
> things: UPDATE pg_class SET relacl = '{ ... anything ...}' WHERE ...
Sure, but the syntax is not an easy one. As a super user, I wish I could
really fix rights with something better than such a syntax, as it is
really ugly and error prone.
> I think our concern with GRANT/REVOKE should be to provide a
> self-consistent set of operations. We're about there AFAICT with respect
> to GRANT/REVOKE themselves, but ALTER OWNER as currently defined breaks
> it.
I agree that the GRANT/REVOKE syntax as basically self consistent wrt
basic users, but it is not necessarily the case wrt a super-user.
Have a nice day,
--
Fabien Coelho - coelho@cri.ensmp.fr
