101

I’m using HomeBrew for my port needs (seems a bit “cleaner” than MacPorts).

I can install without sudoing (which is great), but the man linking step seems to require it (/usr/local/share/man/man3 is owned by root).
A guide I found suggests I recursively chown /usr/local by doing

sudo chown -R `whoami` /usr/local

Is this safe…or is it a Bad Idea™?

Also: are my permissions correct?

$ pwd
/usr/local/share/man
$ ls -lah
total 32
drwxrwxr-x    8 root  staff   272B  4 Set 11:02 .
drwxrwxr-x    9 root  staff   306B 10 Set 11:27 ..
drwxr-xr-x    3 root  wheel   102B  4 Ago  2009 de
drwxrwxr-x  163 root  staff   5,4K 10 Set 11:27 man1
drwxr-xr-x   11 root  wheel   374B 10 Set 11:27 man3
drwxr-xr-x    7 ago   staff   238B 10 Set 11:39 man5
drwxr-xr-x   11 ago   staff   374B 10 Set 11:39 man7
-rw-r--r--    1 root  staff    13K  4 Set 11:02 whatis
Improve this question
6
  • 5
    This is how Homebrew is meant to be used. Some people may disagree but the lead developer says to do things that way.
    – Mike McQuaid
    Sep 15, 2010 at 14:58
  • 1
    Slightly better alternative to your chown: sudo chown -R :admin /usr/local. This way, it'll work the same for any admin user of the machine. Though you may also need to run sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+ to ensure the group has the same write access as the user.
    – Slipp D. Thompson
    Nov 8, 2014 at 21:50
  • 17
    "I'll use homebrew, it feels cleaner than macports. Oh, look at this ill-defined permission mess. I'll check in Stack Overflow. Oh, here's a quick hack that goes against Unix best practices and against what OS updates try to enforce. Perfect!". Month later: "Hey, how did this malware get installed?"
    – hmijail
    Mar 12, 2016 at 9:32
  • 1
    The problem I have with this approach is that it means only the user account which installs Homebrew can use it. I have a Mac with multiple accounts which I use to keep work projects separate from home projects (for example). If I am logged into the wrong account I can't use brew install. I have taken this route to avoid the dangers of using root but I'm not convinced it's the best approach.
    – Auspice
    Apr 21, 2017 at 10:32
  • @MikeMcQuaid I find it interesting that Homebrew has finally admitted fault on this and in the new version released a week or two ago, has restored the default permissions to /usr/local
    – oemb1905
    May 10, 2017 at 12:46

7 Answers 7

Reset to default
41

It is usually better to keep permissions as strict as possible. Keeping /usr/local owned by root means that only processes that run as root/sudo (or ask for admin user via the Apple authorization dialog box) can write to this area. Thus, a process download has to ask you for a password before corrupting files there.

But as you say, it makes adding new programs harder.

I am OK with running sudo, as you install things less often than running them but you have to trust that the build process does not change anything it should.

If you want to avoid sudo I would install Homebrew into ~/usr/local and alter your path, manpath etc to include the directories under there.

A better way is to create another user—say, homebrew and create a directory owned by that user. Then, install there using sudo -U homebrew. Other users will have the benefit of not being able to overwrite any other files, because they are not running as root and other programs cannot affect homebrew. (I note that the Homebrew FAQ does suggest this new user if you are in a "multi user environment". I would say that any Unix machine including macOS is a multi user environment)

However as the Homebrew wiki says the recipes don't find all cases of /usr/local and replace them with the chosen directory I suspect we are stuck with /usr/local.

Improve this answer
4
  • 1
    +1 for keeping authorizations strict, and altering $PATH and $MANPATH to include user directories. If the installed programs don't require systemwide installation, it's a much better alternative.
    – zneak
    Sep 10, 2010 at 13:25
  • 3
    +1 and accepted answer for “keep permissions as strict as possible”. Doing brew doctor (suggested below) told me I only have to chown the shared man directories... safe enough for me.
    – Agos
    Sep 13, 2010 at 10:30
  • 1
    A compromise solution, at least for people caring for security enough to not run as Admin users all the time, is to change the group ownership and permissions so only Admins can write to /usr/local. See kenorb's answer.
    – hmijail
    May 25, 2016 at 9:38
  • 2
    @Mark I find it interesting that Homebrew has finally admitted fault on this and in the new version released a week or two ago, has restored the default permissions to /usr/local
    – oemb1905
    May 10, 2017 at 12:45
54

I use Homebrew too and can confirm it's totally safe. Quoting the Installation page on the official Homebrew FAQ:

Do yourself a favour and pick /usr/local

  1. It’s easier
    /usr/local/bin is already in your PATH.

  2. It’s easier
    Tons of build scripts break if their dependencies aren’t in either /usr or /usr/local. We fix this for Homebrew formulas (although we don’t always test for it), but you’ll find that many RubyGems and Python setup scripts break which is something outside our control.

  3. It’s safe
    Apple has conformed to POSIX and left this directory for us. Which means there is no /usr/local directory by default, so there is no need to worry about messing up existing tools.

If you plan to install gems that depend on brews then save yourself a bunch of hassle and install to /usr/local!

It is not trivial to tell gem to look in non-standard directories for headers and dylibs. If you choose /usr/local, everything “just works!”

I'll just add that doing things as root is a very bad idea, so chowning /usr/local not only seems reasonable to me (it's not a system dir on OSX), but sane.

Your permissions are not correct (yet). Just run the command you listed and you're gonna be fine.

If you have other problems remember, the brew doctor can help you!

Improve this answer
5
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – bmike ♦
    Nov 14, 2015 at 20:03
  • 10
    The chat is gone, which is a pity. So at the risk of repeating history, I will leave my comment here: that this is done doesn't mean that this is safe.
    – hmijail
    Mar 12, 2016 at 9:39
  • 4
    The gist of the chart is although this is what Homebrew suggests there are are reasons as to why this is wrong
    – mmmmmm
    Apr 25, 2016 at 15:45
  • 1
    brew doctor is simply awesome.
    – Utku
    Sep 11, 2016 at 10:26
  • 6
    @Carmine Paolino I find it interesting that Homebrew has finally admitted fault on this and in the new version released a week or two ago, has restored the default permissions to /usr/local
    – oemb1905
    May 10, 2017 at 12:44
13

If you're using Homebrew, you should give the write permission to specific group (either admin or staff), so the files can be shared between users who are in that group.

For example:

sudo chgrp -R admin /usr/local /Library/Caches/Homebrew
sudo chmod -R g+w /usr/local /Library/Caches/Homebrew

Then assign the users who should have access to brew command to that group (check your groups via: id -Gn).

Then when working with brew, do not run it with sudo.

When still having some permission issue, run brew doctor to troubleshoot the problem.

Improve this answer
3
  • +1 for giving an actual, better-behaved-ish solution, even if not really finished. For example: add an user to the admin group at the BSD level? Won't that mess with the OS X's concept of Admin users?
    – hmijail
    Mar 12, 2016 at 9:43
  • For the record, I followed these instructions, but just used my existing OS X GUI-made Admin user instead of adding anyone to any group in the CLI. It works: to be able to run brew commands, I have to first do su myAdminUser, and then everything works as intended. But of course this solution won't give any security for people who anyway are already running an Admin user all the time.
    – hmijail
    May 25, 2016 at 9:31
  • This is probably the best way to go, I agree with @kenorb
    – pixel 67
    Dec 22, 2016 at 9:18
9

For what it's worth, /usr/local is not considered a "system" folder by OS X, and on a brand new Snow Leopard install that folder is empty.

Any root-owned stuff in that folder is a result of sudo make install on other software, or giving your password after double-clicking on a .pkg that wants to dump stuff into /usr/local.

Owning /usr/local has "worked for me" on 2 machines for over a year.

One gotcha is that if you've installed MySQL (not using Homebrew) and chown its files, then it probably won't be able to see its databases anymore (so you'd have to chown them back to whatever user MySQL is running as.)

Improve this answer
6
  • 5
    gcc and other development tools do automatically look in /usr/local so it does affect the system
    – mmmmmm
    Sep 10, 2010 at 17:52
  • 11
    The problem isn't that it's a "system" folder; it's that it is a "systemwide" folder. Even if there's nothing there, /usr/local/bin is still in the default $PATH value, and whatever you put there can be used by other users too and should be trusted. If the whole /usr/local/ directory has the same permissions /usr/local/share/man currently has on OP's setup, anyone can go and change any binary with a script that does rm -rf ~.
    – zneak
    Sep 10, 2010 at 20:33
  • 1
    too risky: it's likely that I will install MySQL sooner or later
    – Agos
    Sep 13, 2010 at 10:29
  • 3
    @Agos: you can always install MySQL with HomeBrew, in which case you won't have any problems :)
    – Carmine Paolino
    Sep 13, 2010 at 12:16
  • 1
    @Agos Not risky at all. The caution only applies if you've installed MySQL before Homebrew. If you do it afterwards the permissions on /usr/local should be fine. (But you probably use Postgres anyway. :) )
    – Marnen Laibow-Koser
    Jan 26, 2014 at 21:03
7

As in Homebrew 1.0.0:

Homebrew no longer needs to have ownership of /usr/local. If you wish you can return /usr/local to its default ownership with: sudo chown root:wheel /usr/local

Improve this answer
2
  • 1
    I'm currently updating Brew using brew update, which still requires ownership of /usr/local. I'll try restoring the permissions afterwards.
    – Joshua Pinter
    Oct 9, 2016 at 15:44
  • This is really great info! I set perms as specified by Homebrew (<1.0), and after updating, it gave these instructions on how to set them back.
    – mortona42
    May 4, 2017 at 18:57
3

As of macOS High Sierra or later, /usr/local can no longer be chown'd.

The Homebrew team now recommends: sudo chown -R $(whoami) $(brew --prefix)/* to fix Homebrew permissions.

See @Carmine Paolino's answer for more info on why Homebrew recommends taking ownership of the Homebrew directories.

Improve this answer
0

I think it's OK for users to have write permissions to /usr/local -- after all, that means you're not using sudo on every build script. I don't like the idea of an ordinary user owning /usr/local. I'd prefer to have root (or similar) own /usr/local, but change the permissions so that users (or at least some privileged group) can write to it. That seems like the conceptually correct approach.

Improve this answer
13
  • 7
    The problem here is that /usr/local/bin may very well be at the front of $PATH for most users. Making the directory world-writable opens a lot of security holes that way.
    – nohillside ♦
    May 29, 2013 at 18:03
  • @patrix So change the paths. :) If you have scripts that have security holes due to ambiguous command paths, I'd blame the scripts, not your permissions -- commands invoked in scripts should usually be fully qualified for exactly this reason. Anyway, there's no better solution: either you give your admin account an insecure umask, or you run all your build scripts with sudo, or you give some users write permissions to /usr/local. I'll take the third as being least risky...unless you know of a better way.
    – Marnen Laibow-Koser
    Jun 1, 2013 at 5:22
  • Hmm. Thinking about this some more, maybe a better way would be to have Homebrew do what RVM does by default: install everything into ~/brew or some such. The problem, though, is that unlike Ruby, which is pretty self-contained, a lot of *nix utilities expect to find each other in /usr/local...
    – Marnen Laibow-Koser
    Jun 1, 2013 at 5:28
  • 3
    I neglected to mention that my /usr/local isn't world-writable: rather, I have a trusted group homebrew (not just admin) that has write permissions to it (extended permissions such as 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherit totally rock). This is the best compromise I've been able to figure out: no sudo on build scripts, but some control over /usr/local.
    – Marnen Laibow-Koser
    Jun 1, 2013 at 5:40
  • @MarnenLaibow-Koser I would love to see a more in-depth explanation of this approach (creating a trusted group of users with write permissions to /usr/local). Doing a lot of trawling on SO and other sites, seeing arguments re: moving Homebrew into the user's home folder vs. keeping in /usr/local, changing owner and/or group of /usr/local or not, and so on… it is difficult to tell if there is any universally acceptable solution. Do you have a blog post or article on this, or could you give a deeper explanation somewhere?
    – Gabriel L.
    Apr 19, 2016 at 14:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .