Re: allowing privileges on untrusted languages

On Sun, Jan 20, 2013 at 10:53 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Yeah. We'd need to think a little bit about how to make this work,
>> since I think that adding a gajillion booleans to pg_authid will not
>> make anyone very happy. But I like the idea. GRANT
>> kill_sessions_of_other_users TO bob? GRANT install_untrusted_pls TO
>> any_database_owner? GRANT install_an_extension_called(hstore) TO
>> any_database_owner? I know there are other ways of doing all of these
>> things, so don't take the specific proposals too seriously, but we
>> clearly have a need to parcel out controlled bits of the superuser
>> mojo to individual users in a nice, clean, convenient way. Getting
>> agreement on the details is likely to be difficult, but it seems like
>> a good concept from 10,000 feet.
>
> The traditional answer to that, which not only can be done already in
> all existing releases but is infinitely more flexible than any
> hard-wired scheme we could implement, is that you create superuser-owned
> security-definer functions that can execute any specific operation you
> want to allow, and then GRANT EXECUTE on those functions to just the
> people who should have it.
>
> I'm really entirely un-thrilled with a proposal to clutter the privilege
> system like this. Admittedly, it might be a hair more secure than
> user-written plpgsql functions, which could perhaps be subverted if the
> author is careless. But there are a hundred other places where we could
> more usefully spend our implementation and future-maintenance efforts
> than here.

It's not terribly personally important to me, either ... but it's
important enough to other people here that I'm pretty sure we will see
future patches aiming at this target. Extensions to event triggers,
inter alia. Even had I the power, I'm not prepared to reject all of
those things out of hand, so I think it would behoove us to think
about by what means we want to enable these sorts of things rather
than whether we want to enable them.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company