Re: Additional role attributes && superuser review - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Additional role attributes && superuser review
Date
Msg-id 20141230130545.GL3062@tamriel.snowman.net
Whole thread Raw
In response to Re: Additional role attributes && superuser review  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Additional role attributes && superuser review  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
* Amit Kapila (amit.kapila16@gmail.com) wrote:
> On Tue, Dec 30, 2014 at 6:52 AM, Stephen Frost <sfrost@snowman.net> wrote:
> > > >There is one issue that occurs to me, however.  We're talking about
> > > >pg_dump, but what about pg_dumpall?  In particular, I don't think the
> > > >DUMP privilege should provide access to pg_authid, as that would allow
> > > >the user to bypass the privilege system in some environments by using
> > > >the hash to log in as a superuser.  Now, I don't encourage using
> > > >password based authentication, especially for superuser accounts, but
> > > >lots of people do.  The idea with these privileges is to allow certain
> > > >operations to be performed by a non-superuser while preventing trivial
> > > >access to superuser.  Perhaps it's pie-in-the-sky, but my hope is to
> > > >achieve that.
> > >
> > > Ugh, hadn't thought about that. :(
> >
> > I don't think it kills the whole idea, but we do need to work out how to
> > address it.
>
> One way to address this might be to allow this only for superusers,

Huh?  The point here is to have a role account which isn't a superuser
who can perform these actions.

> another could be have a separate privilege (DBA) or a role which is
> not a superuser, however can be used to perform such tasks.

I'm pretty sure we've agreed that having a catch-all role attribute like
'DBA' is a bad idea because we'd likely be adding privileges to it later
which would expand the rights of users with that attribute, possibly
beyond what is intended.

> > I don't really like 'xlog' as a permission.  BINARY BACKUP is
> > interesting but if we're going to go multi-word, I would think we would
> > do PITR BACKUP or something FILESYSTEM BACKUP or similar.  I'm not
> > really a big fan of the two-word options though.
>
> How about PHYSICAL BACKUP (for basebackup) and LOGICAL BACKUP
> for pg_dump?

Again, this makes it look like the read-all right would be specific to
users executing pg_dump, which is incorrect and misleading.  "PHYSICAL"
might also imply the ability to do pg_basebackup.

> This is normally the terminology I have seen people using for these
> backup's.

I do like the idea of trying to find a correlation in the documentation
for these rights, though I'm not sure we'll be able to.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Patch: add recovery_timeout option to control timeout of restore_command nonzero status code
Next
From: Heikki Linnakangas
Date:
Subject: Re: What exactly is our CRC algorithm?