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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_ls_dir & friends still have a hard-coded superuser check
Date: 2017-01-25 20:02:21
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers


* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Wed, Jan 25, 2017 at 2:13 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > I went over *every* superuser check in the system when I did that work,
> > wrote up a long email about why I made the decisions that I did, posted
> > it here, had follow-on discussions, all of which lead to the patch which
> > ended up going in.
> Link to that email? I went back and looked at that thread and didn't
> see anything that looked like a general policy statement to me. But I
> may have missed it.

Not sure which thread you were looking at, but this one:

Has a review of all superuser checks in the backend, as noted in the
first paragraph ("shown below in a review of the existing superuser
checks in the backend").

Later on in that thread, at least in:

In an email to you and Noah:
The general approach which I've been using for the default roles is that
they should grant rights which aren't able to be used to trivially make
oneself a superuser.

My recollection is saying that about 10 times during that period of
time, though perhaps I am exaggurating due to it being a rather painful
process to get through.

> I assume we're
> both coming at these issues with the intention of making PostgreSQL
> better;


> the fact that we don't always agree on everything is probably
> inevitable.




In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2017-01-25 20:06:30 Re: PoC plpgsql - possibility to force custom or generic plan
Previous Message Fabien COELHO 2017-01-25 19:58:31 Re: [BUGS] Problem in using pgbench's --connect(-C) and --rate=rate(-R rate) options together.