On 26 January 2017 at 22:36, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
