Date: Sat, 2 Jul 2022 15:16:35 -0700
From: Nathan Bossart <nathandbossart@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Joe Conway <mail@joeconway.com>, Tom Lane <tgl@sss.pgh.pa.us>,
	"Bossart, Nathan" <bossartn@amazon.com>,
	Stephen Frost <sfrost@snowman.net>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Message-ID: <20220702221635.GB1044460@nathanxps13>
References: <20220630232931.GA367181@nathanxps13>
 <CA+TgmoZWWqB66t4K6Mqv6TDttO1YJRJhOJO77B5H9Z8f28yc8Q@mail.gmail.com>
 <20220701025830.GA369935@nathanxps13>
 <12e2f0cb-08ff-c65f-d31e-76cea1af70ec@joeconway.com>
 <CA+TgmoZRO3tO_w+ROHW6Xe1fmQfzVyPuZ5OtbYX40w3YBQkMwA@mail.gmail.com>
 <442d7887-645d-0e31-e971-7a8dc8952d2f@joeconway.com>
 <CA+Tgmoaw_k2jooV214S=2bOBDPPLo7Nnq27-UGp6MNTfk11x5g@mail.gmail.com>
 <CA+TgmoYbjr6F6V3zVp0p4Jjd8jZf9TuCV1iHZ8w-fw9NGanW9w@mail.gmail.com>
 <20220701211225.GA418166@nathanxps13>
 <CA+TgmoaS-RuSxbzRek9SUn-9ZoN=dSw1qXutkvxQegSuZUwYDA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoaS-RuSxbzRek9SUn-9ZoN=dSw1qXutkvxQegSuZUwYDA@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/20220702221635.GB1044460%40nathanxps13>
Precedence: bulk

On Sat, Jul 02, 2022 at 08:45:50AM -0400, Robert Haas wrote:
> I don't think there is a whole lot of point in replacing role-level
> flags with predefined roles that work exactly the same way. Maybe
> there is some point, but I'm not excited about it. The problem with
> these settings in my opinion is that they are too monolithic. Either
> you can create any role with basically any privileges or you can
> create no roles at all. Either you are a superuser and can bypass all
> permissions checks or you are not and can't bypass any permissions
> checks.

Okay.  I see.

>> unparenthesized syntax or add WARNINGs when it is used?)  For [NO]INHERIT
>> and WITH INHERIT DEFAULT, presumably we could do something similar.  Down
>> the road, those would be removed in favor of only using grant-level
>> options.
> 
> I think it'd be hard to do that if WITH INHERIT DEFAULT is actually
> state stored in the catalog. Maybe I should revise this again so that
> the catalog column is just true or false, and the role-level property
> only sets the default for future grants. That might be more like what
> Tom had in mind originally.

I was thinking that when DEFAULT was removed, pg_dump would just need to
generate WITH INHERIT TRUE/FALSE based on the value of rolinherit for older
versions.  Using the role-level property as the default for future grants
seems a viable strategy, although it would break backward compatibility.
For example, if I create a NOINHERIT role, grant a bunch of roles to it,
and then change it to INHERIT, the role won't begin inheriting the
privileges of the roles it is a member of.  Right now, it does.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com