Re: pg_ls_dir & friends still have a hard-coded superuser check

On Fri, Jan 27, 2017 at 1:02 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 26 January 2017 at 22:36, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
>>> 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.
>
> I oppose the patch as currently presented.
>
> In general, I support the viewpoint that we reduce the number of
> superuser checks. I also recognize that its unlikely that this can be
> reduced to zero without a clear way forwards.
>
> What I suggest we do is this
>
> 1. Take the discussion onto the appropriate private forum, which isn't
> here, IMHO.
>
> 2. Try to agree policy first that matches what other security folk
> will allow. Not much point releasing PostgreSQL and then having other
> people block parts of it so it matches their view of security. We
> should seek to resolve that inherent conflict.
>
> 3. Make a list of all functions that would cause security problems.
> One by one, precisely. If we did remove all superuser checks we would
> need this list documented to advise people of the risks, so it must
> exist before any commit can be made, assuming we believe in
> documentation. Notice that I am after risk documentation, not just "By
> default, use of this function is restricted to superusers" because
> that just leads to people exposing themselves unknowingly when they
> follow the next part which seems like official advice, yet is
> potentially unsafe: "access can be given to other users via GRANT".
>
> 4. Later, work towards a patch. We have some weeks to get this right.
>
> I'm willing to spend time on workshopping this in Brussels, with any attendees.

I already added it to the agenda items.

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

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