Обсуждение: system administration functions with hardcoded superuser checks
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?
On 18 December 2012 17:09, Peter Eisentraut <peter_e@gmx.net> 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? +1 But I would include recovery functions also. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
2012/12/18 Peter Eisentraut <peter_e@gmx.net>: > There are some system administration functions that have hardcoded > superuser checks, specifically: > > pg_reload_conf > pg_rotate_logfile > > 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? isn't it too strong gun for some people ??? I believe so some one can decrease necessary rights and it opens doors to system. > pg_read_file > pg_read_file_all > pg_read_binary_file > pg_read_binary_file_all > pg_stat_file > pg_ls_dir is relative dangerous and I am not for opening these functions. power user can simply to write extension, but he knows what he does/ Regards Pavel > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Dec 18, 2012 at 12:09:10PM -0500, 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? +1. You can already use a SECURITY DEFINER wrapper, so I don't think this opens any particular floodgate. GRANT is a nicer interface. However, I would not advertise this as a replacement for wrapper functions until pg_dump can preserve ACL changes to pg_catalog objects.
On Tue, Dec 18, 2012 at 7:41 PM, Noah Misch <noah@leadboat.com> wrote: > On Tue, Dec 18, 2012 at 12:09:10PM -0500, 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? > > +1. You can already use a SECURITY DEFINER wrapper, so I don't think this > opens any particular floodgate. GRANT is a nicer interface. However, I would > not advertise this as a replacement for wrapper functions until pg_dump can > preserve ACL changes to pg_catalog objects. Yeah. That is a bit of a foot-gun to this approach, although I too agree on the general theory. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On 18.12.2012 18:38, Pavel Stehule wrote: > 2012/12/18 Peter Eisentraut <peter_e@gmx.net>: >> There are some system administration functions that have hardcoded >> superuser checks, specifically: >> >> pg_reload_conf >> pg_rotate_logfile >> >> 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? > > isn't it too strong gun for some people ??? > > I believe so some one can decrease necessary rights and it opens doors > to system. No one was speaking about making them executable by a wider group of users by default (i.e. decreasing necessary rights). Today, when you need to provide the EXECUTE privilege on those functions, you have three options (a) make him a superuser - obviously not a good choice (b) create a SECURITY DEFINER wrapper **for each function separately** (c) deny to do that Being able to do a plain GRANT on the function is merely a simpler way to do (b). It has advantages (less objects/functions to care about) and disadvantages (e.g. you can't do additional parameter values checks). >> pg_read_file >> pg_read_file_all >> pg_read_binary_file >> pg_read_binary_file_all >> pg_stat_file >> pg_ls_dir > > is relative dangerous and I am not for opening these functions. > > power user can simply to write extension, but he knows what he does/ I see only dangers that are already present. Tomas
On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra <tv@fuzzy.cz> wrote: > On 18.12.2012 18:38, Pavel Stehule wrote: >> 2012/12/18 Peter Eisentraut <peter_e@gmx.net>: >>> There are some system administration functions that have hardcoded >>> superuser checks, specifically: >>> >>> pg_reload_conf >>> pg_rotate_logfile >>> >>> 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? >> >> isn't it too strong gun for some people ??? >> >> I believe so some one can decrease necessary rights and it opens doors >> to system. > > No one was speaking about making them executable by a wider group of > users by default (i.e. decreasing necessary rights). Today, when you > need to provide the EXECUTE privilege on those functions, you have three > options Given how limited these functions are in scope, I don't see a problem here. >>> pg_read_file >>> pg_read_file_all >>> pg_read_binary_file >>> pg_read_binary_file_all >>> pg_stat_file >>> pg_ls_dir >> >> is relative dangerous and I am not for opening these functions. >> >> power user can simply to write extension, but he knows what he does/ > > I see only dangers that are already present. Granting executability on pg_read_xyz is pretty darn close to granting superuser, without explicitly asking for it. Well, you get "read only superuser". If we want to make that step as easy as just GRANT, we really need to write some *very* strong warnings in the documentation so that people realize this. I doubt most people will realize it unless we do that (and those who don't read the docs, whch is probably a majority, never will). If you use SECURITY DEFINER, you can limit the functions to *the specific files that you want to grant read on*. Which makes it possible to actually make it secure. E.g. you *don't* have to give full read to your entire database. If you're comparing it to a blanket SECURITY DEFINER with no checks, then yes, it's a simpler way to fire the cannon into your own foot, yes. But if also gives you a way that makes it more likely that you don't *realize* that you're about to fire a cannon into your foot. --Magnus HaganderMe: http://www.hagander.net/Work: http://www.redpill-linpro.com/
On 19 December 2012 06:34, Magnus Hagander <magnus@hagander.net> wrote: > Granting executability on pg_read_xyz is pretty darn close to granting > superuser, without explicitly asking for it. Well, you get "read only > superuser". If we want to make that step as easy as just GRANT, we > really need to write some *very* strong warnings in the documentation > so that people realize this. I doubt most people will realize it > unless we do that (and those who don't read the docs, whch is probably > a majority, never will). Good point. Can we do that explicitly with fine grained superuser-ness? GRANT SUPERUSER ON FUNCTION .... TO foo; > If you use SECURITY DEFINER, you can limit the functions to *the > specific files that you want to grant read on*. Which makes it > possible to actually make it secure. E.g. you *don't* have to give > full read to your entire database. Even better point > If you're comparing it to a blanket SECURITY DEFINER with no checks, > then yes, it's a simpler way to fire the cannon into your own foot, > yes. But if also gives you a way that makes it more likely that you > don't *realize* that you're about to fire a cannon into your foot. -- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
On 19.12.2012 07:34, Magnus Hagander wrote: > On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra <tv@fuzzy.cz> wrote: >> On 18.12.2012 18:38, Pavel Stehule wrote: >>> 2012/12/18 Peter Eisentraut <peter_e@gmx.net>: >>>> There are some system administration functions that have hardcoded >>>> superuser checks, specifically: >>>> >>>> pg_reload_conf >>>> pg_rotate_logfile >>>> >>>> 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? >>> >>> isn't it too strong gun for some people ??? >>> >>> I believe so some one can decrease necessary rights and it opens doors >>> to system. >> >> No one was speaking about making them executable by a wider group of >> users by default (i.e. decreasing necessary rights). Today, when you >> need to provide the EXECUTE privilege on those functions, you have three >> options > > Given how limited these functions are in scope, I don't see a problem here. > >>>> pg_read_file >>>> pg_read_file_all >>>> pg_read_binary_file >>>> pg_read_binary_file_all >>>> pg_stat_file >>>> pg_ls_dir >>> >>> is relative dangerous and I am not for opening these functions. >>> >>> power user can simply to write extension, but he knows what he does/ >> >> I see only dangers that are already present. > > Granting executability on pg_read_xyz is pretty darn close to granting > superuser, without explicitly asking for it. Well, you get "read only > superuser". If we want to make that step as easy as just GRANT, we > really need to write some *very* strong warnings in the documentation > so that people realize this. I doubt most people will realize it > unless we do that (and those who don't read the docs, whch is probably > a majority, never will). Yup, that's what I meant by possibility to perform "additional parameter values checks" ;-) Tomas
Tomas Vondra <tv@fuzzy.cz> writes:
> On 19.12.2012 07:34, Magnus Hagander wrote:
>> Granting executability on pg_read_xyz is pretty darn close to granting
>> superuser, without explicitly asking for it. Well, you get "read only
>> superuser". If we want to make that step as easy as just GRANT, we
>> really need to write some *very* strong warnings in the documentation
>> so that people realize this. I doubt most people will realize it
>> unless we do that (and those who don't read the docs, whch is probably
>> a majority, never will).
> Yup, that's what I meant by possibility to perform "additional parameter
> values checks" ;-)
Yeah, which is easily done if you've written a wrapper function and not
so easily otherwise. Between that and the point about how pg_dump
wouldn't preserve GRANTs done directly on system functions, I think this
proposal isn't going anywhere anytime soon.
regards, tom lane
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.
Вложения
2013/1/15 Peter Eisentraut <peter_e@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 <kaigai@kaigai.gr.jp>