public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tom Lane <[email protected]>
To: Robert Haas <[email protected]>
Cc: Mark Dilger <[email protected]>
Cc: David G. Johnston <[email protected]>
Cc: Stephen Frost <[email protected]>
Cc: Joshua Brindle <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: role self-revocation
Date: Wed, 09 Mar 2022 16:01:40 -0500
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmobgeK0JraOwQVPqhSXcfBdFitXSomoebHMMMhmJ4gLonw@mail.gmail.com>
References: <CAGB+Vh4Qb4+5zrJ2pJio6rxy2+hnt2zhTmonxgzfF3wY4H6WRw@mail.gmail.com>
<CA+Tgmob_rJtHdjMOqiOcGtk0vU6XXjOqQ0LSvVpUJjvdY341rw@mail.gmail.com>
<[email protected]>
<CA+TgmobNfJvG6keNU6YcykJnntDm_-BxN_5JDacakusr5E0hEg@mail.gmail.com>
<CAKFQuwb3=Zdp2-mEPWbTmktt3NLRNdprGi7=DqfG-pxpTQo43w@mail.gmail.com>
<CA+TgmoY9SLMEpCcVFw9gs-9_ihK+3T7P0_4zkMDfXk8DfvheYA@mail.gmail.com>
<[email protected]>
<CA+TgmoaARcSQzzhGpX2z5C-xb3DAr0SHDMPHqhh1VHCRHFm0WA@mail.gmail.com>
<[email protected]>
<CA+TgmoZPUnhez=TxeUceJV2Xu2Gg35MwYzyC9QgdPDKsvxyUyg@mail.gmail.com>
<[email protected]>
<[email protected]>
<CA+TgmoY8wkrFXw3dPO+NDvqazutHF6x3UQcy-eAjLgxoj8xN=A@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<CA+TgmobgeK0JraOwQVPqhSXcfBdFitXSomoebHMMMhmJ4gLonw@mail.gmail.com>
Robert Haas <[email protected]> writes:
> On Mar 7, 2022, at 12:16 PM, Tom Lane <[email protected]> wrote:
> tgl> Having said that, one thing that I find fishy is that it's not clear
> tgl> where the admin privilege for a role originates. After "CREATE ROLE
> tgl> alice", alice has no members, therefore none that have admin privilege,
> tgl> therefore the only way that the first member could be added is via
> tgl> superuser deus ex machina. This does not seem clean.
> I agree with that, but I don't think it's a sufficient reason for
> keeping the self-admin exception, because the same problem exists for
> non-login roles. I don't even think it's the right idea conceptually
> to suppose that the power to administer a role originates from the
> role itself.
Actually, that's the same thing I was trying to say. But if it doesn't
originate from the role itself, where does it originate from?
> 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).
regards, tom lane
view thread (24+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: role self-revocation
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox