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?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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_dirSome 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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_logfileSome 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
--
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_dirSome 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.
--
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 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_dirSome 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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_logfileSome 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_diris 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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_logfileSome 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_diris 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 Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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_logfileSome 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
optionsGiven 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_diris 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
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_dirSome 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.
Attachments:
pg-func-superuser-checks.patchtext/plain; charset=UTF-8; name=pg-func-superuser-checks.patch; x-mac-creator=0; x-mac-type=0Download
diff --git a/src/backend/catalog/system_views.sql b/src/backend/catalog/system_views.sql
index c479c23..f6c2c53 100644
--- a/src/backend/catalog/system_views.sql
+++ b/src/backend/catalog/system_views.sql
@@ -773,3 +773,16 @@ CREATE FUNCTION ts_debug(IN document text,
CREATE OR REPLACE FUNCTION
pg_start_backup(label text, fast boolean DEFAULT false)
RETURNS text STRICT VOLATILE LANGUAGE internal AS 'pg_start_backup';
+
+
+/*
+Revoke privileges for functions that should be accessible by
+superusers only by default. We can't set the privileges in pg_proc.h,
+because bootstrap mode doesn't handle aclitem arrays.
+*/
+REVOKE EXECUTE ON FUNCTION pg_read_file(text, bigint, bigint) FROM PUBLIC;
+REVOKE EXECUTE ON FUNCTION pg_read_file(text) FROM PUBLIC;
+REVOKE EXECUTE ON FUNCTION pg_read_binary_file(text, bigint, bigint) FROM PUBLIC;
+REVOKE EXECUTE ON FUNCTION pg_read_binary_file(text) FROM PUBLIC;
+REVOKE EXECUTE ON FUNCTION pg_stat_file(text) FROM PUBLIC;
+REVOKE EXECUTE ON FUNCTION pg_ls_dir(text) FROM PUBLIC;
diff --git a/src/backend/utils/adt/genfile.c b/src/backend/utils/adt/genfile.c
index f53c7d4..c545dd8 100644
--- a/src/backend/utils/adt/genfile.c
+++ b/src/backend/utils/adt/genfile.c
@@ -174,11 +174,6 @@
int64 bytes_to_read = PG_GETARG_INT64(2);
char *filename;
- if (!superuser())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- (errmsg("must be superuser to read files"))));
-
filename = convert_and_check_filename(filename_t);
if (bytes_to_read < 0)
@@ -198,11 +193,6 @@
text *filename_t = PG_GETARG_TEXT_P(0);
char *filename;
- if (!superuser())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- (errmsg("must be superuser to read files"))));
-
filename = convert_and_check_filename(filename_t);
PG_RETURN_TEXT_P(read_text_file(filename, 0, -1));
@@ -219,11 +209,6 @@
int64 bytes_to_read = PG_GETARG_INT64(2);
char *filename;
- if (!superuser())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- (errmsg("must be superuser to read files"))));
-
filename = convert_and_check_filename(filename_t);
if (bytes_to_read < 0)
@@ -243,11 +228,6 @@
text *filename_t = PG_GETARG_TEXT_P(0);
char *filename;
- if (!superuser())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- (errmsg("must be superuser to read files"))));
-
filename = convert_and_check_filename(filename_t);
PG_RETURN_BYTEA_P(read_binary_file(filename, 0, -1));
@@ -267,11 +247,6 @@
HeapTuple tuple;
TupleDesc tupdesc;
- if (!superuser())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- (errmsg("must be superuser to get file information"))));
-
filename = convert_and_check_filename(filename_t);
if (stat(filename, &fst) < 0)
@@ -331,11 +306,6 @@
struct dirent *de;
directory_fctx *fctx;
- if (!superuser())
- ereport(ERROR,
- (errcode(ERRCODE_INSUFFICIENT_PRIVILEGE),
- (errmsg("must be superuser to get directory listings"))));
-
if (SRF_IS_FIRSTCALL())
{
MemoryContext oldcontext;
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_dirSome 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>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers