Re: ACLs versus ALTER OWNER - Mailing list pgsql-hackers

From Tom Lane
Subject Re: ACLs versus ALTER OWNER
Date
Msg-id 23626.1086183233@sss.pgh.pa.us
Whole thread Raw
In response to Re: ACLs versus ALTER OWNER  (Fabien COELHO <coelho@cri.ensmp.fr>)
Responses Re: ACLs versus ALTER OWNER
List pgsql-hackers
Fabien COELHO <coelho@cri.ensmp.fr> writes:
> 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
that flow from "nowhere" (i.e., are not traceable through an unbroken
chain to the original owner's grant options).  The changes we have been
making recently are specifically designed to prevent such situations,
and I don't really wish to backtrack.

It's worth pointing out also that the superuser can always brute-force
things:
UPDATE pg_class SET relacl = '{ ... anything ...}' WHERE ...

and so we don't really need to provide escape hatches in GRANT/REVOKE
that are only useful to superusers.  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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Merlin Moncure"
Date:
Subject: Re: [pgsql-hackers-win32] select like...not using index
Next
From: Tom Lane
Date:
Subject: Re: ACLs versus ALTER OWNER