On Fri, Jan 27, 2017 at 1:02 PM, Simon Riggs <si...@2ndquadrant.com> wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers