Re: fixing CREATEROLE - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: fixing CREATEROLE
Date
Msg-id 04EB240E-C177-41E9-B4D5-D4B7096312BB@enterprisedb.com
Whole thread Raw
In response to Re: fixing CREATEROLE  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: fixing CREATEROLE
List pgsql-hackers

> On Nov 23, 2022, at 12:04 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>
>> But if that's the case, did I misunderstand upthread that these are properties the superuser specifies about Alice?
CanAlice just set these properties about herself, so she gets the behavior she wants?  I'm confused now about who
controlsthese settings. 
>
> Because they are role-level properties, they can be set by whoever has
> ADMIN OPTION on the role. That always includes every superuser, and it
> never includes Alice herself (except if she's a superuser). It could
> include other users depending on the system configuration. For
> example, under this proposal, the superuser might create alice and set
> her account to CREATEROLE, configuring the INHERITCREATEDROLES and
> SETCREATEDROLES properties on Alice's account according to preference.
> Then, alice might create another user, say bob, and make him
> CREATEROLE as well. In such a case, either the superuser or alice
> could set these properties for role bob, because alice enjoys ADMIN
> OPTION on role bob.

Ok, so the critical part of this proposal is that auditing tools can tell when Alice circumvents these settings.
Withoutthat bit, the whole thing is inane.  Why make Alice jump through hoops that you are explicitly allowing her to
jumpthrough?  Apparently the answer is that you can point a high speed camera at the hoops. 

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: drop postmaster symlink
Next
From: Justin Pryzby
Date:
Subject: Re: Documentation for building with meson