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

From Dave Page
Subject Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check
Date
Msg-id CA+OCxoyhigBCPLikXFQ5-EQpzAC8VXx8nYEav5Hry+-Kn3ActQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superusercheck  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] pg_ls_dir & friends still have a hard-coded superuser check  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
On Thu, Jan 26, 2017 at 10:36 PM, Stephen Frost <sfrost@snowman.net> wrote:
>
> Perhaps unsuprisingly, but you've still not convinced me, so I don't
> agree with this change.
>
>> Currently, I count three votes in favor of this approach and one
>> opposed.  If anyone else wants to weigh in, please do.  It would be
>> helpful if anyone weighing in can be clear about whether (a) they are
>> in favor of the patch as proposed, or (b) they are not in favor of the
>> patch as proposed but could support a narrower patch that removed the
>> checks only from functions with no known escalate-to-superuser risks,
>> or (c) they oppose all change.  It would also be helpful if the
>> reasons why each person takes the position that they do could be
>> mentioned.
>
> I agree that it'd be nice if others would weigh in on this.

As a general point I'm entirely in favour of removing any superuser
checks and replacing them either with standard GRANT ACL config, or
where appropriate, some other type of permission that we can grant to
roles as needed. Probably the most common complaint I get from users
regarding the management & monitoring tools I work on is that they
have to use superuser accounts to get the full benefits, unlike other
DBMSs where you can create a role with just the required privileges
(or indeed, other DBMSs that ship with such roles pre-defined for
convenience).

-- 
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: [HACKERS] GSoC 2017
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Failure in commit_ts tap tests