Hacker News Reader

Comment by lisper | Hacker News Reader

I have very mixed feelings about homebrew. When it works, it is awesome, but when it doesn't it can be a serious nightmare. In particular, homebrew refuses to run under sudo. Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm). I have mostly stopped using it for this reason.

I understand that running a program that runs third-party scripts under sudo is a security nightmare, but there has to be a better solution than globally chowning /usr/local.

[UPDATE] Apparently, this is no longer the case. Good to know!

[UPDATE2] Alas, the problem seems to not have been fully addressed. You still need to chown /usr/local/bin :-(

View on HN

> recursively chown /usr/local to myself

As of 1.0.0: you don't need to do this any more and we don't ask you to.

Ah, that is very good to know! Thank you! I will take a fresh look at homebrew. :-)

To perhaps save you some effort: we still ask you to chown e.g. `/usr/local/bin` which may or may not make it unacceptable to you.

That's not quite as bad as all of /usr/local, but still not great. Why "e.g."? What else is there? And why not just use /usr/local/homebrew or even better, a path determined by an environment variable? I don't mind giving you a user-owned directory to install things in. I mind very much being required to change system default security settings.

You can use a different directory, though some packages may be broken:

https://github.com/Homebrew/brew/blob/master/docs/Installati...

Yeah, that's kind of the situation I'm in. So for any given package it's a crap shoot whether or not it will work. (And if it doesn't work, uninstalling it can be a real problem!) Hence my continued mixed feelings about homebrew in general.

We don't require you to take ownership of any directories that already exist when macOS is installed (i.e. `/usr/local` subdirectories but not `/usr/local` itself). Regardless of whether we should have picked another path, changing now would require rebuilding all our binary packages and that's a lot of effort with little return and almost certain breakages.

I haven't done a clean install of OS X in a long time, but I'm pretty sure /usr/local/bin exists. But even if it doesn't I don't find this a compelling argument. Having /usr/local/bin owned by root is a universally accepted standard in the unix world, and with very good reason: having /usr/local/bin owned by a user introduces security risks.

`/usr/local` is empty on a new install. I reconfirmed with a clean install VM.

I believe /usr/local/bin is empty on a fresh install.

It should be -- after all, it's there for local software.

What are those risks?

/usr/local/bin is a global resource. It is generally full of binaries that get run by many different users including root. If a regular user can replace those binaries the result is a privilege escalation.

which programs from /usr/local/bin get run by root under current macOS?

Well, by default /usr/local/bin is empty. But people commonly install things there that eventually get run by root. The most obvious example is various programming languages, different versions of Python, alternate shells, etc.

(Reaching back into foggy memory...) The last time I installed Homebrew, I think I had the problem that `/usr/local/bin` didn't exist, and I didn't have write permissions for `/usr/local/` so I couldn't create it (w/out sudo/chown) etc. This, using Sierra.

Does that seem likely? Usual? What's the ideal solution?

You need to use `sudo` as a one-off thing when you install Homebrew. Our installer does that for you otherwise we'll prompt you with `brew doctor`.

Why don't you have your binaries installed in a user-owned directory like ~/brew or whatever, and then put that at the front of the path? Asking people to `chown` a system path is plainly a contravention of the principle of least privilege.

`~/brew` varies from username to username and requires us to be able to relocate all binaries so they reference the correct path. We do this for as many as possible but it's not possible for all of them.

I'm on an older version (0.9.5); how do I fix the ownership of my /usr/local tree?

EDIT: I know how to `chown`, I mean more, what can I give back to root, what needs to remain under homebrew's control? Does the new version ship with a tool/command that does this?

`brew update` and check you've not hit the update bug: https://github.com/homebrew/brew#update-bug

We'll tell you what permissions you need to keep/remove. Alternatively, uninstall and reinstall Homebrew and similarly we'll tell you on permissions.

> Instead, to instal in /usr/local it wants me to recursively chown /usr/local to myself, which is a Really Bad Idea (tm).

Why is this a really bad idea for a personal machine? The only problems I can think of are some subdirectories that are conventionally given some other user ownership to make running a related server under a specific user, and the problem of putting potentially arbitrary probably unreviewed executables in a system-wide path. But the former problem is one you wrestle with anyway if /usr/local is owned by root. And the latter problem... you're going to have some path where you're putting all this stuff, and it's either going to be a personally owned or system owned path. The system-owned choice means giving your package manager sudo and having to run things with sudo (which, without attention, means giving the executables system-wide access). What other problems does a personally owned path create? What's the alternative?

> Why is this a really bad idea for a personal machine?

It's a security risk. Having user access to /usr/local allows me (or, more to the point, an attacker running as me and not root) to surreptitiously replace system binaries, some of which may be run by other users. Some of those other users may have access to parts of the system that I don't have. Some of those other users may even be running as root.

> What's the alternative?

/usr/local/homebrew/bin. Or even better /opt/homebrew/bin. Or even better, a path that is set in an environment variable.

Other than being in a different directory, what difference is that going to make? You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.

Also you can actually install it wherever you like, this is just the default/recommended location:

https://github.com/Homebrew/brew/blob/master/docs/Installati...

Other than being in a different directory, what difference is that going to make?

Because, if they had picked their own directory and not a standard one like /usr/local/bin, then they would only be putting the homebrew installed binaries at risk. It would be better for defense in depth if they had not. As it is, all of their users are incentivized to unnecessarily give up a little security in favor of convenience. It's precisely that mindset that's one of the "enemies." (The other "enemy" is security without concern for convenience. We know from practice that's just as broken.)

You are going to have both in your $PATH in order to run the binaries, so if an attacker can write to either bad stuff could happen.

Normally, you'd need root privileges to write to /usr/local/bin. Since it's a very popular location for installing 3rd party tools, homebrew is effectively incentivizing users to have more writable executables than otherwise.

Homebrew also aids security by making it easier for devs to keep executables updated. They also deserve credit for making something useful. I use homebrew as well. However, I still really wish they would've made a different decision about /usr/local/bin.

/usr/local/bin is a global resource populated by binaries run by many different users including root. Making it user-writable opens the door to privilege escalation attacks by replacing binaries that are then run by other users.

Why would using /opt/homebrew/bin stop these sorts of attacks?

It would prevent privilege escalation attacks on binaries that I have already installed in /usr/local/bin. Yes, packages installed in /opt/homebrew/bin could be attacked separately, but at least the vulnerable binaries are isolated so it's easier to keep an eye on them and make sure none of them are ever run with privileges.

But you're right: to really fix this problem requires that homebrew change its installation process entirely.

> What's the alternative?

Install software as root, eg by invoking sudo.

The "don't compile as root" argument is correct, that too is a bad idea. But that's exactly why traditional "./configure; make; sudo make install" instructions separate the initial build (using the default make target) from a the install target.

It's why binary packages for basically every platform are built using a controlled, non root-user environment, but installed using root-equivalent permissions.

This was a problem for me. I installed Homebrew to my home directory [1] and it works great. I no longer need to chown /usr/local or run any commands under sudo.

[1] https://gist.github.com/jaymcgavren/bb85914950578edabad190c3...

I do the same (but installed to ~/.homebrew). No issues so far — if anyone knows why this isn't the default, I'd be interested to know.

I have the same concerns and have been using Nix for my Mac package manager [1] instead. Functionally it's far better, though with far fewer packages available currently.

[1]:https://news.ycombinator.com/item?id=11772686

I've been meaning to try out Nix for probably years. I work in vfx and large facilities have particular needs that most packaging systems don't support, but there's a huge about of investment that can be leveraged (dependency resolution, caching).

I did a fresh install of macOS with Sierra and decided to use Nix instead of Homebrew this time around. So far I've only started reading through the docs and only have a few things installed; git, vim, tmux. What are your thoughts about using it as a Homebrew alternative?

I've been using Homebrew for years and have been a huge fan so far. I often look at formulas when trying to build things from scratch on Linux.

If you're considering it for a Homebrew alternative, the main thing is to make a list of all the packages you must have, and then all the ones you would like to have, and then check if they're in Nix. Decide whether you can live with that or not.

Besides that, it's great. The about page sums its features up nicely: http://nixos.org/nix/about.html

>Functionally it's far better

For example?

The about page sums its features up pretty well, see if there's anything that particularly appeals to you there: http://nixos.org/nix/about.html

Also the HN link in my previous comment has some good discussion of it, just scroll down past the initial Docker comparison thread.

For me the main benefit of it is that I trust it. It doesn't take over system directories like Homebrew, which bugs me even though I'm on a single-user system where that should be ok. Both installs and uninstalls are deterministic, complete, and don't screw anything else up in the system. You can install different versions of the same package side-by-side, which the Debian and Red Hat Alternatives systems also enable, but Nix is more sophisticated about it tagging everything with a cryptographic hash of its build tree. MacPorts and pkgsrc may also provide some of this, but Nix feels more like the git of package managers than anything else I've used, eg the one that finally gets packaging right.

Isn't it desirable to run builds as not-root?

If you're concerned about safety, you could maybe "freeze" your homebrew install by chowning /usr/local back to root in between brew invocations.

> Isn't it desirable to run builds as not-root?

Absolutely. That's why the canonical gnu installation separates "make" from "make install". But homebrew could do the same thing (and maybe it does now -- I need to go back and revisit this because apparently this issue has been resolved.)

Very much the reason why MacPorts requires sudo, so it can drop to a less-privileged "macports" user for builds, without putting your own user account at risk.

Not to rain on anyone's parade, but I find MacPorts to be superior to Homebrew in every way, from writing the ports themselves, to installing them and managing them. I used to use Homebrew some time ago, but when I got my Mac Mini, I decided to forgo it in favor of MacPorts and Pkgsrc (which Joyent also provides binaries of for OSX). Whatever MacPorts doesn't have (a rare occurrence), Pkgsrc tends to have it. If not, writing a MacPort is incredibly easy with their provided DSL.

I was pleasantly surprised that, despite Homebrew taking so much of the OSX package management mind-share these days, MacPorts still has an active and vibrant community going strong. I was also pleasantly surprised by just how well Pkgsrc works on OSX, despite its origins on NetBSD. In fact, Pkgsrc works so well that I've switched to using it on Slackware as my primary package manager for anything not in the base system, preferring it to SlackBuilds.org and sbotools (though I still use sbotools whenever Pkgsrc doesn't have a package I want — which sometimes leads to duplicate dependencies in different paths... still haven't figured out how to avoid that yet...).

As a side note and in fact late to the party, but MacPorts very recently also migrated to Git and GitHub: https://github.com/macports/

I agree, I prefer MacPorts also. It has a more of a linux/debian package management vibe to it, which I like.

I've tried homebrew also, but it just feels more like a hack put together. Maybe version 1.1.0 is better, but I'm still going to stick with MacPorts.

Each to it's own, but I wish MacPorts would get more coverage in the news and in the OS X development world.

Just install to a different folder. Everything still works.

I wonder how much of this could have been avoided if they defaulted to a different, user created folder.

Reply on news.ycombinator.com