Re: Switching to Homebrew as recommended Mac install?

From: Jay Levitt <jay(dot)levitt(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dave Page <dpage(at)pgadmin(dot)org>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Switching to Homebrew as recommended Mac install?
Date: 2012-04-03 19:14:44
Message-ID: 4F7B4C24.10900@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Thomas Kellerer 2012-04-03 19:45:01 Re: views, queries, and locks
Previous Message Merlin Moncure 2012-04-03 19:13:58 Re: views, queries, and locks

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2012-04-03 21:09:56 Re: log chunking broken with large queries under load
Previous Message Robert Haas 2012-04-03 18:58:25 Re: invalid search_path complaints