Re: Switching to Homebrew as recommended Mac install? - Mailing list pgsql-hackers

From Jay Levitt
Subject Re: Switching to Homebrew as recommended Mac install?
Date
Msg-id 4F7B4C24.10900@gmail.com
Whole thread Raw
In response to Re: Switching to Homebrew as recommended Mac install?  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas wrote:
> On Mon, Apr 2, 2012 at 5:23 AM, Dave Page<dpage@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.

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 postgresql.org 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 README.md
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.

Jay


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: invalid search_path complaints
Next
From: Andrew Dunstan
Date:
Subject: Re: log chunking broken with large queries under load