Re: Switching to Homebrew as recommended Mac install?

On Tue, Apr 3, 2012 at 8:22 AM, Robert Haas <robertmhaas(at)gmail(dot)com> 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.

+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?"