Robert Haas wrote:
On Mon, Apr 2, 2012 at 5:23 AM, Dave Page<>  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.

In fairness to Dave, I think he was still reacting to my initial proposal that homebrew be the *recommended* install. In that case, people might install homebrew specifically because recommended it.

If the consensus is that /usr/local/* user-writable is insecure, I certainly wouldn't object to a little note that said "If you're using homebrew, do 'brew install postgresql', but we don't recommend homebrew for security reasons; a little pressure might provide the impetus for homebrew to allow a better way.

That said, about 8 months ago Homebrew's defaults changed. It no longer requires /usr/local to be directly writable; it will sudo if necessary during the initial installation to create its subdirectories. Those directories are mostly user-writable, though:

% ls -l /usr/local
total 8
drwxr-xr-x   37 jay   admin   1.2K Mar 31 16:39 Cellar/
drwxr-xr-x    7 jay   admin   238B Feb 29 10:51 Library/
-rw-r--r--    1 jay   admin   789B Feb 29 10:57
drwxr-xr-x  499 jay   admin    17K Apr  1 15:29 bin/
drwxr-xr-x    9 jay   admin   306B Mar  7 16:23 etc/
drwxr-xr-x   69 jay   admin   2.3K Mar 16 16:48 include/
drwxr-xr-x  178 jay   admin   5.9K Mar 16 16:48 lib/
drwxr-xr-x    3 root  admin   102B Mar 14 13:20 man/
drwxr-xr-x   20 jay   admin   680B Mar 31 16:40 share/
drwx------    3 jay   admin   102B Feb 29 11:43 var/

At no point was anything in /usr/local *world*-writable, FWIW.

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 think the brew designers expect most folks to either not have anything in /usr/local from outside homebrew, to not install anything there as root, to understand the security consequences, or to use homebrew as root even though it's unsupported, and deal with their own bugs.

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.

Packaging systems? I thought that's called "all software ever"!

brew's lucky in that the Mac by definition is not a heterogeneous environment, and so Mac users don't expect it to be. (Last I checked, it's either difficult, impossible or unsupported to boot from a volume other than your filesystem root.) By being mostly source-fetch-only, sitting on top of git, and not packaging either system-provided features (many of which would require root) or repackaging gems/eggs/nodes, they've avoided a lot of the hard problems. But sure, it's only two years old and it will get more complex over time.


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to