Skip site navigation (1) Skip section navigation (2)


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: (view raw, whole thread or download thread mbox)
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

	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


pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group