Re: allowing for control over SET ROLE

On Thu, Jan 12, 2023 at 10:21:32AM -0500, Robert Haas wrote:
> On Thu, Jan 12, 2023 at 12:09 AM Noah Misch <noah@leadboat.com> wrote:

> > > --- a/doc/src/sgml/ref/grant.sgml
> > > +++ b/doc/src/sgml/ref/grant.sgml
> > > @@ -298,6 +298,20 @@ GRANT <replaceable class="parameter">role_name</replaceable> [, ...] TO <replace
> > >     This option defaults to <literal>TRUE</literal>.
> > >    </para>
> > >
> > > +  <para>
> > > +   To create an object owned by another role or give ownership of an existing
> > > +   object to another role, you must have the ability to <literal>SET
> > > +   ROLE</literal> to that role; otherwise, commands such as <literal>ALTER
> > > +   ... OWNER TO</literal> or <literal>CREATE DATABASE ... OWNER</literal>
> > > +   will fail.  However, a user who inherits the privileges of a role but does
> > > +   not have the ability to <literal>SET ROLE</literal> to that role may be
> > > +   able to obtain full access to the role by manipulating existing objects
> > > +   owned by that role (e.g. they could redefine an existing function to act
> > > +   as a Trojan horse).  Therefore, if a role's privileges are to be inherited
> > > +   but should not be accessible via <literal>SET ROLE</literal>, it should not
> > > +   own any SQL objects.
> > > +  </para>
> >
> > I recommend deleting the phrase "are to be inherited but" as superfluous.  The
> > earlier sentence's mention will still be there.  WITH SET FALSE + NOINHERIT is
> > a combination folks should not use or should use only when the role has no
> > known privileges.
> 
> I don't think I agree with this suggestion. If the privileges aren't
> going to be inherited, it doesn't matter whether the role owns SQL
> objects or not. And I think that there are two notable use cases for
> SET FALSE + NOINHERIT (or SET FALSE + INHERIT FALSE). First, the a
> grant with SET FALSE, INHERIT FALSE, ADMIN TRUE gives you the ability
> to administer a role without inheriting its privileges or being able
> to SET ROLE to it. You could grant yourself those abilities if you
> want, but you don't have them straight off. In fact, CREATE ROLE
> issued by a non-superuser creates such a grant implicitly as of
> cf5eb37c5ee0cc54c80d95c1695d7fca1f7c68cb.

That is a valid use case, but Trojan horse matters don't apply there.

> Second, SET FALSE, INHERIT
> FALSE could be used to set up groups for pg_hba.conf matching without
> conferring privileges.

That is factual, but doing this and having that role own objects shouldn't be
considered a best practice.  It's a bit like using the address of a function
as an enum value.  Instead of role own_some_objects_and_control_hba, the best
practice would be to have two roles, own_some_objects / control_hba.

Since the text is superfluous but not wrong, I won't insist.