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

From Stephen Frost
Subject Re: Additional role attributes && superuser review
Date
Msg-id 20141016132147.GV28859@tamriel.snowman.net
Whole thread Raw
In response to Re: Additional role attributes && superuser review  (Petr Jelinek <petr@2ndquadrant.com>)
List pgsql-hackers
* Petr Jelinek (petr@2ndquadrant.com) wrote:
> 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).

k. :)

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

Yeah.  Not sure if that should only exist as an extension, but that's
really a conversation for a different thread.

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

Really curious what untrusted language you're referring to which isn't
as risky as others..?  Any kind of filesystem or network access, or the
ability to run external commands, is dangerous to give non-superusers.

Perhaps more to the point- what would the more granular solution look
like..?  Though, this is still getting a bit off-topic for this thread.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: WIP: dynahash replacement for buffer table
Next
From: Andres Freund
Date:
Subject: Re: WIP: dynahash replacement for buffer table