2013/1/15 Peter Eisentraut <pete...@gmx.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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
