Re: role self-revocation - Mailing list pgsql-hackers

From Robert Haas
Subject Re: role self-revocation
Date
Msg-id CA+Tgmob9+PLuhP2Bqfr9rde9_C+xoSxj6HyKm9s6nQ7syfJKPw@mail.gmail.com
Whole thread Raw
In response to Re: role self-revocation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: role self-revocation  (Stephen Frost <sfrost@snowman.net>)
Re: role self-revocation  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 9, 2022 at 4:01 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > In my opinion, the right to
> > administer a role - regardless of whether or not it is a login role -
> > most naturally vests in the role that created it, or something in that
> > direction at least, if not that exact thing.
>
> This seems like a reasonable answer to me too: the creating role has admin
> option implicitly, and can then choose to grant that to other roles.
> Obviously some work needs to be done to make that happen (and we should
> see whether the SQL spec has some different idea).

Well, the problem is that as far as I can see, the admin option is an
optional feature of membership. You can grant someone membership
without admin option, or with admin option, but you can't grant them
the admin option without membership, just like you can't purchase an
upgrade to first class without the underlying plane ticket. What would
the syntax look even like for this? GRANT foo TO bar WITH ADMIN OPTION
BUT WITHOUT MEMBERSHIP? Yikes.

But do we really have to solve this problem before we can clean up
this session exception? I hope not, because I think that's a much
bigger can of worms than this is.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: [Proposal] vacuumdb --schema only
Next
From: Stephen Frost
Date:
Subject: Re: role self-revocation