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