Re: allowing privileges on untrusted languages

2013/1/11 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> Here is a proposed patch for the issue discussed in
> <http://archives.postgresql.org/pgsql-hackers/2012-07/msg00569.php>:
>
> I'd propose getting rid of lanplistrusted, at least for access
> checking. Instead, just don't install USAGE privileges by
> default for those languages.
>
> The reason is that there is value in having a role that can
> deploy
> schemas, possibly containing functions in untrusted languages,
> without having to be a full superuser. Just like you can have a
> user that can create roles without being a superuser.
>
> It turned out that actually getting rid of lanpltrusted would be too
> invasive, especially because some language handlers use it to determine
> their own behavior.
>
> So instead the lanpltrusted attribute now just determined what the
> default privileges of the language are, and all the checks the require
> superuserness to do anything with untrusted languages are removed.
>
Even though I could understand your motivation, I'm worrying about this
change makes system security uncontrollable. For example, it allows
an unprivileged users to grant usage permission of untrusted language
for another one or public, without any controls by superuser.

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.

Does it make sense for your efforts? Probably, these three may match with
what you focus on, as a first step.
* privilege to read/write local filesystem
* privilege to use untrusted language
* other privileges; that does not match above ones.

How about your opinion?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>