99

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
Glorfindel
  • 3,774
  • 7
  • 30
  • 46
Agos
  • 3,524
  • 5
  • 25
  • 28
  • 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 '10 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 08 '14 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 '16 at 09:32
  • 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 '17 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 '17 at 12:46
  • @Agos See comment above – oemb1905 May 10 '17 at 12:46

7 Answers7

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!

dcastro
  • 103
  • 3
Carmine Paolino
  • 1,962
  • 2
  • 17
  • 18
  • Comments are not for extended discussion; this conversation has been [moved to chat](http://chat.stackexchange.com/rooms/31567/discussion-on-answer-by-carmine-paolino-are-my-permissions-for-usr-local-corre). – bmike Nov 14 '15 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 '16 at 09: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 '16 at 15:45
  • 1
    `brew doctor` is simply awesome. – Utku Sep 11 '16 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 '17 at 12:44
40

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.

mmmmmm
  • 28,660
  • 17
  • 84
  • 140
  • 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 '10 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 '10 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 '16 at 09: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 '17 at 12:45
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.

kenorb
  • 12,217
  • 17
  • 81
  • 140
  • +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 '16 at 09: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 '16 at 09:31
  • This is probably the best way to go, I agree with @kenorb – pixel 67 Dec 22 '16 at 09: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.)

jherran
  • 12,964
  • 11
  • 55
  • 72
Adam Vandenberg
  • 269
  • 1
  • 4
  • 5
    gcc and other development tools do automatically look in /usr/local so it does affect the system – mmmmmm Sep 10 '10 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 '10 at 20:33
  • 1
    too risky: it's likely that I will install MySQL sooner or later – Agos Sep 13 '10 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 '10 at 12:16
  • @CarminePaolino Not a great idea. Usually Mac installers such as MySql provides are better behaved than even a very good package manager like Homebrew. – Marnen Laibow-Koser Jan 26 '14 at 21:01
  • 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 '14 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

Yuhao Zhang
  • 317
  • 4
  • 7
  • 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 09 '16 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 04 '17 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.

Matias
  • 141
  • 4
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.

Marnen Laibow-Koser
  • 109
  • 4
  • 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 '13 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 01 '13 at 05: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 01 '13 at 05: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 01 '13 at 05: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 '16 at 14:57
  • @GabrielL. boils down to do you have more than one user (and also my answer) if so which one user should own /usr/local – mmmmmm Apr 25 '16 at 15:47
  • @GabrielL. What part don't you understand? If you understand how *nix permissions work, and think about who should be able to write to `/usr/local`, setup should be self-evident. – Marnen Laibow-Koser Apr 26 '16 at 18:56
  • @MarnenLaibow-Koser — thanks for the reply. It's not that I don't understand it, so much as I don't know what I don't know. ;-) Mostly I was trying to discern what the potential cons / downsides of that approach might be. It does seem like a good compromise. – Gabriel L. Apr 26 '16 at 19:33
  • @GabrielL. Homebrew suggest this way in their FAQ but for a "multi-uer-environment" – mmmmmm Dec 24 '17 at 09:50
  • @Marnen: we should note that since Catalina /usr/local is a firmlink, so you can't create an ACL for it. So you need to do it for the sub-directories. I just tried it, and it works: /usr/local/bin is root:wheel, but the ACL for group _brew allows access. However, your own account needs to be a member of that group too. And then every process running as your user will still be able to write to those sub-directories, without root privileges. We need a way to make it work *without* adding your own user to that group. Is there a way to switch your user to a group it doesn't belong to? – JayB Jun 15 '20 at 21:21
  • No… strike that last question: if you add your user to group _brew, you will still remain in staff (20). Then `brew doctor` will tell you that /usr/local/bin is not writable. If you switch to group _brew with `newgrp brew`, then `brew doctor` will not flag /usr/local/bin. So this is actually a pretty decent solution. – JayB Jun 15 '20 at 21:32
  • PS no, seems only to have worked in the original Terminall session. After a new login, the _brew group is accepted, 501 and _brew are "married", and you don't need to change groups to write to /usr/local/bin… so no added security with this approach. So the original question still stands: Is there a way to switch a user to a group it's not a member of? – JayB Jun 15 '20 at 21:52
  • @JayB You can add a user to any groups you like. – Marnen Laibow-Koser Jun 23 '20 at 15:38