Take the 2-minute tour ×
Ask Different is a question and answer site for power users of Apple hardware and software. It's 100% free, no registration required.

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
$ 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
share|improve this question
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
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 '14 at 21:50

4 Answers 4

up vote 12 down vote accepted

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.

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.

share|improve this answer
+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
+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

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

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!

share|improve this answer
-1 changing ownership of system folders is a bad, bad idea. The whole point of UNIX permissions is to ensure that people can't just break anything they (or a malicious process) wants to. If some change is made necessary by a user's needs, sudo is there. –  zneak Sep 10 '10 at 13:20
(I can't edit my other comment anymore) You should make the difference between system-owned programs and user-owned programs. Do you need to make the binaries available to everyone? If so, you do well to put them in /usr/local, and it would be better if this folder's ownership remained to the system (since it's available systemwide). Otherwise, you should install them in directories you own (like ~/bin and ~/man, that you'll very likely have to create yourself). What if certain binaries in /usr/local depended on the set UID bit? –  zneak Sep 10 '10 at 13:30
@zneak: please read the official wiki wiki.github.com/mxcl/homebrew/installation –  Carmine Paolino Sep 10 '10 at 15:24
@zneak: sudo is more dangerous than changing permissions to a folder and installing as a user instead –  Carmine Paolino Sep 10 '10 at 18:19
the more I think of it, the more sense it makes to me to install as normal user. If I execute a malicious (or botched) install script, the amount of damage I can do as myself is less than as root. And other users should not have more problems executing programs in /usr/local owned by me than if they were owned by root. –  Victor Jalencas Sep 16 '10 at 23:01

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.)

share|improve this answer
gcc and other development tools do automatically look in /usr/local so it does affect the system –  Mark Sep 10 '10 at 17:52
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
too risky: it's likely that I will install MySQL sooner or later –  Agos Sep 13 '10 at 10:29
@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
@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

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.

share|improve this answer
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. –  patrix 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 1 '13 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 '13 at 5:28
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 '13 at 5:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.