On 26 January 2017 at 22:36, Stephen Frost <sfrost@snowman.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.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services