Re: system administration functions with hardcoded superuser checks

2013/1/15 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On 12/18/12 12:09 PM, Peter Eisentraut wrote:
>> There are some system administration functions that have hardcoded
>> superuser checks, specifically:
>>
>> pg_reload_conf
>> pg_rotate_logfile
>> pg_read_file
>> pg_read_file_all
>> pg_read_binary_file
>> pg_read_binary_file_all
>> pg_stat_file
>> pg_ls_dir
>>
>> Some of these are useful in monitoring or maintenance tools, and the
>> hardcoded superuser checks require that these tools run with maximum
>> privileges. Couldn't we just install these functions without default
>> privileges and allow users to grant privileges as necessary?
>
> This is still being debated, but just for the heck of it, here is a
> patch for how this implementation would look like.
>
Even though it gives flexibility of system configuration, it seems to me too
less-grained access control because above function accept arbitrary
path name, thus, privilege to execution of these function also allows to
reference arbitrary access.

Here are two type of access controls. One is subject-verb-object type;
that describes subject's permitted actions on a particular object.
GRANT/REVOKE command specifies which objects are scope of this
privilege. SELinux is also SVO type.
On the other hand, second is subject-verb type. Superuser privilege
is applied independent from the object. I never heard a root user who
cannot perform as superuser on /etc directory, for example.
I think, it is a reasonable design that above functions right now requires
superuser privilege because it can take arbitrary pathname.

My preference is, above functions (and others that takes pathname
arguments) check SVO style permissions, instead of hardcoded
superuser privilege.
For example, is it a senseless idea to have a mapping table between
database user and operating system user, then call access(2) to
check whether mapped os user have privilege to access this file?

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