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


From: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ACLs versus ALTER OWNER
Date: 2004-06-03 10:10:50
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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(at)cri(dot)ensmp(dot)fr

In response to

pgsql-hackers by date

Next:From: Teodor SigaevDate: 2004-06-03 12:27:59
Subject: Re: New btree_gist code has a few problems
Previous:From: Andreas PflugDate: 2004-06-03 08:10:10
Subject: Re: Compiling libpq with VisualC

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