Re: SET ROLE and reserved roles - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: SET ROLE and reserved roles
Date
Msg-id 20160505144146.GP10850@tamriel.snowman.net
Whole thread Raw
In response to Re: SET ROLE and reserved roles  (Stephen Frost <sfrost@snowman.net>)
Responses Re: SET ROLE and reserved roles  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
* Stephen Frost (sfrost@snowman.net) wrote:
> * Robert Haas (robertmhaas@gmail.com) wrote:
> > On Tue, Apr 26, 2016 at 7:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> > > On Mon, Apr 25, 2016 at 6:55 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > >> Based on our discussion at PGConf.US and the comments up-thread from
> > >> Tom, I'll work up a patch to remove those checks around SET ROLE and
> > >> friends which were trying to prevent default roles from possibly being
> > >> made to own objects.
> > >>
> > >> Should the checks, which have been included since nearly the start of
> > >> this version of the patch, to prevent users from GRANT'ing other rights
> > >> to the default roles remain?  Or should those also be removed?  I
> > >> *think* pg_dump/pg_upgrade would be fine with rights being added, and if
> > >> we aren't preventing ownership of objects then we aren't going to be
> > >> able to remove such roles in any case.
> > >
> > > It'd be good to test that that works.  If it does, I think we may as
> > > well allow it.
> > >
> > >> Of course, with these default roles, users can't REVOKE the rights which
> > >> are granted to them as that happens in C code, outside of the GRANT
> > >> system.
> > >
> > > I think you mean that they can't revoke the special magic rights, but
> > > they could revoke any additional privileges which were granted.
> > >
> > >> Working up a patch to remove these checks should be pretty quickly done
> > >> (iirc, I've actually got an independent patch around from when I added
> > >> them, just need to find it and then go through the committed patches to
> > >> make sure I take care of everything), but would like to make sure that
> > >> we're now all on the same page and that *all* of these checks should be
> > >> removed, making default roles just exactly like "regular" roles, except
> > >> that they're created at initdb time and have "special" rights provided
> > >> by C-level code checks.
> > >
> > > That's what I'm thinking.  I would welcome other views.
> >
> > Ping!
>
> Thanks.  I'm planning to post a patch tomorrow to remove these checks.

Apologies about not getting to this yesterday, was pretty busy finding
pre-existing issues in pg_dump.

Attached is a patch which removes the various special checks that I had
added to prevent using default roles like regular roles.  As noted in
the commit message, users are still prevented from creating roles in the
"pg_" namespace and from ALTER'ing those roles, but otherwise they're
very much like regular roles.

I've adjusted the regression tests accordingly, but I'm going to do more
testing to make sure that pg_dump handles them correctly (and will be
adding cases to my pg_dump TAP test suite to ensure that they stay
working) over the next day or so.

Barring objections or concerns, I'll push this sometime tomorrow
(probably after I get back to DC).

Thanks!

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Rodrigo Cavalcante
Date:
Subject: Re: Pg_stop_backup process does not run - Backup Intervals
Next
From: David Rowley
Date:
Subject: Re: pg9.6 segfault using simple query (related to use fk for join estimates)