Re: allowing privileges on untrusted languages
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Kohei KaiGai <kaigai@kaigai.gr.jp>, Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgresql.org
Date: 2013-01-20T14:10:47Z
Lists: pgsql-hackers
On Sat, Jan 19, 2013 at 8:54 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On 19 January 2013 13:45, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote: >> I think, it is a time to investigate separation of database superuser privileges >> into several fine-grained capabilities, like as operating system doing. >> https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h >> >> In case of Linux, the latest kernel has 36 kinds of capabilities that reflects >> a part of root privileges, such as privilege to open listen port less than 1024, >> privilege to override DAC permission and so on. Traditional root performs >> as a user who has all the capability in default. > > Sounds like the best way to go. The reasoning that led to that change > works for us as well. 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company