From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Petr Jelinek <petr(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Additional role attributes && superuser review |
Date: | 2014-10-16 13:21:47 |
Message-ID: | 20141016132147.GV28859@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* Petr Jelinek (petr(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-10-16 13:30:15 | Re: WIP: dynahash replacement for buffer table |
Previous Message | Robert Haas | 2014-10-16 13:19:16 | Re: WIP: dynahash replacement for buffer table |