On Thu, Jun 02, 2022 at 12:26:48PM -0400, Robert Haas wrote:
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway <mail@joeconway.com> wrote:
>> > It seems to me that the INHERIT role flag isn't very well-considered.
>> > Inheritance, or the lack of it, ought to be decided separately for
>> > each inherited role. However, that would be a major architectural
>> > change.
>>
>> Agreed -- that would be useful.
>
> Is this a kind of change people would support? Here's a quick sketch:
Yes.
> The idea here is that, today, a role must either inherit privileges
> from all roles of which it is a member or none of them. With this
> proposal, you could make a role inherit some of those privileges but
> not others. I think it's not difficult to see how that might be
> useful: for example, user A could be granted non-login role X with
> inheritance and login role B without inheritance. That would allow
> user A to exercise the privileges of a member of group X at all times,
> and the privileges of user B only with an explicit SET ROLE operation.
> That way, A is empowered to act for B when necessary, but won't
> accidentally do so.
I think we should also consider replacing role attributes with predefined
roles. I'm not sure that this proposal totally prepares us for such a
change, given role attributes apply only to the specific role for which
they are set and aren't inherited. ISTM in order to support that, we'd
need even more enhanced functionality. For example, if I want 'robert' to
be a superuser, and I want 'joe' to inherit the privileges of 'robert' but
not 'pg_superuser', you'd need some way to specify inheriting only certain
privileges possessed by an intermediate role.
--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com