Thread: Remove default privilege from DB

Greetings,

* David G. Johnston (david.g.johnston@gmail.com) wrote:
> On Fri, Feb 16, 2018 at 7:56 AM, Durumdara <durumdara@gmail.com> wrote:
>
> > I want to know what happened in the background.
> > I will make "negative" state if I revoke DefACL without prior grant?
>
> ​Not really following the whole thread but figured I'm comment on this
> point that confused me in the past as well.​
>
> ​Not sure if this is what you mean but there is no concept of "negative
> state" in the permissions system.  Everything starts out with no
> permissions.  Grant adds permissions and revoke un-adds granted
> permissions.​  Revoking something that doesn't exist is either a no-op or a
> warning depending on the context - either way its doesn't setup a
> "forbidden" state for the permission.

This isn't entirely correct.  Functions are the classic example where
EXECUTE to PUBLIC is part of the default and the "negative" state of
having a function where EXECUTE is REVOKE'd from PUBLIC is entirely
reasonable and even common.

Further, object owners also have a default set of privileges which can
be revoked from them, and that's true of basically all objects.

> Revoking/granting on default ACLs never affects already existing objects.

Right, to change existing ACLs one would use GRANT ON ALL or individual
GRANT statements.

Thanks!

Stephen

Stephen Frost <sfrost@snowman.net> writes:
> * David G. Johnston (david.g.johnston@gmail.com) wrote:
>> ​Not sure if this is what you mean but there is no concept of "negative
>> state" in the permissions system.  Everything starts out with no
>> permissions.  Grant adds permissions and revoke un-adds granted
>> permissions.​  Revoking something that doesn't exist is either a no-op or a
>> warning depending on the context - either way its doesn't setup a
>> "forbidden" state for the permission.

> This isn't entirely correct.  Functions are the classic example where
> EXECUTE to PUBLIC is part of the default and the "negative" state of
> having a function where EXECUTE is REVOKE'd from PUBLIC is entirely
> reasonable and even common.

FWIW, I thought David's description was fine.  The fact that the initial
state of an object typically includes some positive grants doesn't change
the fact that there's no such thing as a negative grant.  In particular,
if there is a GRANT TO PUBLIC, no amount of revoking that privilege from
individual users will have any effect, because the public grant is still
there.

            regards, tom lane

Tom,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * David G. Johnston (david.g.johnston@gmail.com) wrote:
> >> ​Not sure if this is what you mean but there is no concept of "negative
> >> state" in the permissions system.  Everything starts out with no
> >> permissions.  Grant adds permissions and revoke un-adds granted
> >> permissions.​  Revoking something that doesn't exist is either a no-op or a
> >> warning depending on the context - either way its doesn't setup a
> >> "forbidden" state for the permission.
>
> > This isn't entirely correct.  Functions are the classic example where
> > EXECUTE to PUBLIC is part of the default and the "negative" state of
> > having a function where EXECUTE is REVOKE'd from PUBLIC is entirely
> > reasonable and even common.
>
> FWIW, I thought David's description was fine.  The fact that the initial
> state of an object typically includes some positive grants doesn't change
> the fact that there's no such thing as a negative grant.  In particular,
> if there is a GRANT TO PUBLIC, no amount of revoking that privilege from
> individual users will have any effect, because the public grant is still
> there.

What I was particularly picking up on was the comment that "Everything
starts out with no permissions" which implied, at least to me, the idea
that no one has any rights on an object until those rights are GRANT'd,
which isn't correct, as I described.

Thanks!

Stephen