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-07-02 12:45:50
Message-ID: CA+TgmoaS-RuSxbzRek9SUn-9ZoN=dSw1qXutkvxQegSuZUwYDA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jul 1, 2022 at 5:12 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
> > I have some hesitations about this approach. On the positive side, I
> > believe it's fully backward compatible, and that's something to like.
> > On the negative side, I've always felt that the role-level properties
> > - [NO]INHERIT, [NO]CREATEROLE, [NO]SUPERUSER, [NO]CREATEDB were hacky
> > kludges, and I'd be happier they all went away in favor of more
> > principled ways of controlling those behaviors. I think that the
> > previous design moves us in the direction of being able to eventually
> > remove [NO]INHERIT, whereas this, if anything, entrenches it.
>
> +1. As mentioned upthread [0], I think attributes like CREATEROLE,
> SUPERUSER, and CREATEDB could be replaced with predefined roles. However,
> since role attributes aren't inherited, that would result in a behavior
> change. I'm curious what you have in mind. It might be worth spinning off
> a new thread for this sooner than later.

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.

> 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.

More clear sketch: Remove WITH INHERIT DEFAULT and just have WITH
INHERIT { TRUE | FALSE }. If neither is specified, the default for a
new GRANT is set based on the role-level property. I want more control
than that.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2022-07-02 14:24:51 Re: Support logical replication of DDLs
Previous Message Robert Haas 2022-07-02 12:34:04 Re: pg15b2: large objects lost on upgrade