On Tue, Apr 3, 2012 at 8:22 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Apr 2, 2012 at 5:23 AM, Dave Page <dp...@pgadmin.org> wrote: >> If homebrew intentionally creates a hole like that, then for as long >> as I'm one of the PostgreSQL webmasters it will *never* be listed on >> our download pages. > > I think that's a bit harsh. It's not as if the PostgreSQL package > creates the security hole; it's something that the packaging system > does itself, independent of whether or not you try to install > PostgreSQL with it. So it seems to me that refusing to list it is > making life difficult for people who have already made the decision to > use brew, without any compensating advantage.
+1. If someone has decided that they want to use homebrew on their Mac, then they have accepted the whole class of issues of this sort for a bunch of *other* software. I don't think Postgres is that much more special. And note that if they're using Ruby to access the Postgres instance, and there are (perceived) security holes with the Ruby toolchain's installation, it doesn't much matter if the Postgres installation is 'more secure', it's being accessed via a layer that is already Plenty Holey. > That doesn't mean that I approve of brew's approach to this problem, > though. Even if you think that it's unimportant to keep the desktop > user from usurping root privileges, having some things installed in > /usr/local as root and others as the desktop user (multiple different > desktop users?) seems like a recipe for chaos. I've made those types > of mistakes, but I got them out of my system in the nineties. I can't > help but wonder if this isn't just the natural way a packaging system > evolves - you start with something very simple (like what brew is now) > and then gradually you realize that there are some annoyances, so you > file those down by adding some more complexity, and eventually you end > up with a system that's just as complex as the ones that you > originally thought were too complex. I suspect that this is Yet Another Case of people using a mostly "desktop/single user" system building something that's perfectly convenient for that case. It's pretty typical for MacOS applications to require "enter your password; I need to su to root to install this!" in plenty of places where the UI does not actually tell you what is being done as root. After enough iterations of "enter your password so my process can do undisclosed admin stuff," I'm not sure that you've got anything more secure than you'd have if /usr/local was writable by the desktop user. I'm not sure you can successfully wrench people in that environment into a "proper" multi-user setup. It took Microsoft *years* to get it to a semblance of working, and people still have a flurry of "oh, click this to give administrative permissions" activities that are *begging* to be an exploit. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?" -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers