Re: replacing role-level NOINHERIT with a grant-level option

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: replacing role-level NOINHERIT with a grant-level option
Date: 2022-06-02 19:37:34
Message-ID: CA+TgmobLsD4JOEBZNMb9hYyr3MN6b8tb4LTY=PnmZ+7S5dj6mQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 2, 2022 at 2:07 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> 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.

I guess we could think about adding something like an ONLY clause,
like GRANT ONLY robert TO joe. I feel a little bit uncomfortable about
that, though, because it assumes that robert is a superuser but his
own privileges are distinguishable from those of the superuser. Are
they really? If I can assume robert's identity, I can presumably
Trojan my way into the superuser account pretty easily. I'll just
define a little trigger on one of his tables. I don't really see a way
where we can ever make it safe to grant a non-superuser membership in
a superuser role.

But even if there is a way, I think that is a separate patch from what
I'm proposing here. [NO]INHERIT only has to do with what privileges
you can exercise without SET ROLE. To solve the problem you're talking
about here, you'd need a way to control what privileges are conferred
in any manner, which is related, but different.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-06-02 19:40:37 Re: pg_auth_members.grantor is bunk
Previous Message Andres Freund 2022-06-02 19:17:55 Re: [RFC] building postgres with meson