Re: Additional role attributes && superuser review

* Petr Jelinek (petr@2ndquadrant.com) wrote:
> On 15/10/14 07:22, Stephen Frost wrote:
> >   First though, the new privileges, about which the bikeshedding can
> >   begin, short-and-sweet format:
> >
> >   BACKUP:
> >     pg_start_backup()
> >     pg_stop_backup()
> >     pg_switch_xlog()
> >     pg_create_restore_point()
>
> As others have commented, I too think this should support pg_dump.

I'm uttly mystified as to what that *means*.  Everyone asking for it is
great but until someone can define what "support pg_dump" means, there's
not much progress I can make towards it..

pg_dump doesn't require superuser rights today.  If you're looking for a
role which allows a user to arbitrairly read all data, fine, but that's
a different consideration and would be a different role attribute, imv.
If you'd like the role attribute renamed to avoid confusion, I'm all for
that, just suggest something.

> >   For posterity's sake, here's my review and comments on the various
> >   existing superuser checks in the backend (those not addressed above):
> >
> >   CREATE EXTENSION
> >     This could be a role attribute as the others above, but I didn't
> >     want to try and include it in this patch as it has a lot of hairy
> >     parts, I expect.
>
> Yeah it will, mainly because extensions can load modules and can
> have untrusted functions, we might want to limit which extensions
> are possible to create without being superuser.

The extension has to be available on the filesystem before it can be
created, of course.  I'm not against providing some kind of whitelist or
similar which a superuser could control..  That's similar to how PLs
work wrt pltemplate, no?

> >   tcop/utility.c
> >     LOAD (load shared library)
>
> This already somewhat handles non-superuser access. You can do LOAD
> as normal user as long as the library is in $libdir/plugins
> directory so it probably does not need separate role attribute
> (might be somehow useful in combination with CREATE EXTENSION
> though).

Ah, fair enough.  Note that I wasn't suggesting this be changed, just
noting it in my overall review.

> >   commands/functioncmds.c
> >     create untrusted-language functions
>
> I often needed more granularity there (plproxy).

Not sure what you're getting at..?  Is there a level of 'granularity'
for this which would make it safe for non-superusers to create
untrusted-language functions?  I would think that'd be handled mainly
through extensions, but certainly curious what others think.

> >   commands/functioncmds.c
> >     execute DO blocks with untrusted languages
>
> I am not sure if this is significantly different from
> untrusted-language functions.

Nope, just another case where we're doing a superuser() check.
Thanks!
    Stephen