Re: Additional role attributes && superuser review

On 16/10/14 13:44, Stephen Frost wrote:
> * 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..

The explanation you wrote to Jim makes sense, plus given the comment 
from Magnus about REPLICATION flag I guess I am happy enough with it (I 
might have liked to have REPLICATION flag to somehow be part of BACKUP 
flag but that's very minor thing).

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

Makes sense, there is actually extension called pgextwlist which does this.

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

I've been in situation where I wanted to give access to *some* untrusted 
languages to non-superuser (as not every untrusted language can do same 
kind of damage) and had to solve it via scripting outside of pg.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services