Re: ACLs versus ALTER OWNER

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ACLs versus ALTER OWNER
Date: 2004-06-02 13:33:53
Message-ID: 23626.1086183233@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fabien COELHO <coelho(at)cri(dot)ensmp(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2004-06-02 13:38:12 Re: ACLs versus ALTER OWNER
Previous Message Merlin Moncure 2004-06-02 12:07:23 Re: [pgsql-hackers-win32] select like...not using index