Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Date
Msg-id CA+TgmoY=HeN2yV1R0_NDqvMgdPPe2wYM=94dWDnb13npDpn1pQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
On Wed, Jan 25, 2017 at 2:08 PM, Stephen Frost <sfrost@snowman.net> wrote:
> That isn't what you're doing with those functions though, you're giving
> the monitoring tool superuser-level rights but trying to pretend like
> you're not.

Uh, how so?  None of those functions can be used to escalate to
superuser privileges.  I am trying to give SOME superuser privileges
and not others.  That IS how good security works.

I don't really think it's necessary to outline the use case more than
I have already.  It's perfectly reasonable to want a monitoring tool
to have access to pg_ls_dir() - for example, you could use that to
monitor for relation files orphaned by a previous crash.  Also, as
mentioned above, I don't think this should have to be litigated for
every single function individually.  If it's a good idea for a
non-superuser to be able to pg_start_backup() and pg_stop_backup(),
the person doing that has access to read every byte of data in the
filesystem; if they don't, there's no point in giving them access to
run those functions.  Access to just pg_ls_dir(), for example, can't
be any more dangerous than that.  Indeed, I'd argue that it's a heck
of a lot LESS dangerous.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check