Skip site navigation (1) Skip section navigation (2)

Re: system administration functions with hardcoded superuser checks

From: Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: system administration functions with hardcoded superuser checks
Date: 2013-01-16 09:43:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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?

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2013-01-16 10:31:54
Subject: Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Previous:From: Daniel FarinaDate: 2013-01-16 09:37:04
Subject: Re: Parallel query execution

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group