>  it should follow common unix standards

Isn't /usr/local?

    > or at least fit in with OSX

It did - before now /usr/local was available unprivileged with ownership.

    > rather than require a hack

It only needs that now, since requirements to "fit in with OSX" have changed. That's not Homebrew's fault - they need a fast solution. Kudos in my book for responding before it's a problem.

No, /usr/local is normally 755 root:root (or whatever the effective equivalent is). Homebrew wants it to be 775 root:admin, so that users with the admin bit can write to it. That's not standard.

People keep writing here as if El Cap removes /usr/local entirely. It does not. /usr/local is there by default. You only have to go into recovery mode if you've somehow removed it yourself.

> Homebrew wants it to be 775 root:admin

It's worse than that. Homebrew wants 775 $(whoami):admin.

quesera's reply points-out just how bad it is, but even for just 775 root:admin I would have to use sudo (plus edit the sudoers or /usr/bin/login -p first) anyway:

  $ /usr/bin/env -i /bin/sh -c \
    'id | grep -lw admin >/dev/null && echo admin || echo non-admin'
  non-admin

The problem is I have no problem using sudo, but homebrew does (like it wants make all to happen as me).

Yeah, the more I read this thread, the more I'm thinking "why is that?" - `apt-get` et al have no problem with you using sudo, why does `brew` scare you into an alternative? 'because Mac'?

I can't think of anything more standard than /usr/local/.

BSD and Linux use /usr/local, it's not universal.

But /usr/local has never been writable by non-privileged users.

Homebrew depends on that nonstandard and undesireable permissions model. Apple doesn't bend to accommodate an inappropriate use.

Hombrew doesn't want to use a location that is outside the default PATH, and they don't want to install with proper permissions, so they purposefully misinterpret the "standard".

Hijinks ensue, and people blame Apple, which is silly.

A. There is no real standard here B. Apple doesn't bend, period. They don't actually care whether the use is appropriate or inappropriate. C. Blaming this on homebrew is hilarious

Remind me again why i should need to reboot into recovery mode to create a directory?

You need to boot into recovery mode to create /usr/local (or to disable SIP altogether) because /usr is immutable, so that code executing under an admin account can't inject itself into binaries (or into PATHs) under /usr.

I use Homebrew and will probably keep doing that because Homebrew is really convenient and just generally works better than MacPorts for me, but what Homebrew is demanding --- ownership over /usr/local --- is not in fact reasonable. It makes a lot of sense to me that OSX will want to keep perms on /usr/local (which is in everyone's PATH) locked down, and so it seems extra hacky that they're going to add a 'brew doctor' check to see if Software Update has "broken" those privileges.

The commenter upthread that suggested Homebrew should use ~/.homebrew or something by default is right.

And I contend that homebrew did not want to used ~/.homebrew because that would mean modifying files to add it to PATH and be additional testing for people that write recipes.

And that's totally fine, and I let Homebrew own /usr/local too. What I'm not going to do is freak out when a totally sane and useful security feature breaks that install mode, especially when I could, if I cared that much about convenience, just take 30 seconds to disable the security feature.

I just want to make clear I'm not freaking out (and I know you're not either).

I would hope though that out of this someone would think, "Hmm... oh drat... yeah I guess this is just one of those things that nobody predicted at first. Shot I think it was a bad idea to have a user own /usr/local/. But you know, it's a good time to improve things... hmm... I know let's build and stage as nobody and then copy under /usr/local/! We still can have binary packages always work and nobody has to mess with PATH, man pages, or dynamic linker trivia. We might have to write something though that asks for a username and password, but whoa... OSX makes that surprisingly easy... I should do that!"

It's not going to be me cause I don't use homebrew, but that would be way better than these hacks that will ammount to people being encouraged to just disable SIP cause of the headache after ever software update.

Keep in mind that you can re-enable SIP right after you create the directory, if you had to create it at all.

A. /usr/local has never ever been writable by a nonprivileged user. Every standard that exists, including the principle of least surprise, is emphatic on that point. The security implications of "any other way" are massive.

B. If Linus or the FHS changed their ways in this, there would be outrage. It's inappropriate and just plain dumb. [edit: I shouldn't have said "dumb", please replace with "in violation of all guarantees of system integrity".]

C. See above.

You apparently have issues with SIP. That's a separate issue from the current thread, but OK. You should reboot to securely change nvram settings that will allow you to manipulate the protected zone of the file system (including /usr) because this concession to inconvenience saves you from privilege escalation attacks.

The real question is why you deleted /usr/local in the first place. It's standard OSX, and always has been. If you deleted it before SIP, but object to its absence now that SIP applies to the directory where it lives...I'm not sure how to help.

A. Single user systems are not the same as server systems, and plenty of single user systems have had the equivalent of /usr/local as writable. If you want to argue this security is worth it, that's a different argument. I suspect most people who just want to get shit done are going to find it a huge pain in the ass.

You can also argue these people are stupid.

As for standards, vendors follow FHS and friends exactly as far as it helps them justify whatever they want to do.

If you really want to argue from the perspective that "this is standard and that's the reason it's done", that seems awfully silly to me given the layout and other permissions of apple systems.

It's pretty non-FHS/etc to have /Applications be writable, for example.

B. let's be clear: there is outrage no matter what is changed and why, and the argument is always "it is inappropriate and dumb". So this statement is fairly independent of this change.

A. OSX is not a single user system. It inherits from various Unixes, and no Unix has ever had nonprivileged writability on any directory under /usr.

FHS does not apply to OSX in any way. Why do people think so?

Also, /Applications is not writable by nonprivileged users either!

Agreed on ~"changes yield outrage", but in this case, it's just a software application vendor violating obvious historical and specific guidelines from software OS vendor, and people blaming OS vendor when things break. This perplexes me.

You might just as productively argue that there is no such thing as a modern single-user system, since Windows isn't that either. His point is pretty clear.

OTOH: The debate here is a little confusing. What SIP is doing w/r/t/ /usr/local isn't unprecedented; securelevels and the immutable flag could have the same effect on OpenBSD all the way back in the 1990s.

> You might just as productively argue that there is no such thing as a modern single-user system, since Windows isn't that either. His point is pretty clear.

Correct, and nonprivileged users can't install software globally on Windows either. Because it's now a modern OS, and that's how things are done. For very good reasons.

His point, as far as I can tell, amounts to: applications should be able to trash permissions on convenient directories and not have the OS complain or repair their damage.

Perhaps I'm being ungenerous here? I apologize if so.

On re read, I realize that tptacek is responding only to the SIP part of the discussion. OK, SIP is surprising to desktop computer users. But it's a good feature that requires a little adjustment to work with. But really not much, and none for the vast majority of users who don't muck with system directories.

He's arguing that users should be able to elevate their privileges by supplying root's credentials and then create a simple directory without having to reboot.

I more agree with you than with him, but his argument seems pretty straightforward.

Well, if you unwind far enough, I think the original discussion was about why Homebrew has trouble using /usr/local. Where "using" means "owning, adding git repos to, changing permissions on, etc".

OSX suggests /usr/local as a good location to install software, but insists that the directory itself be owned by root, and protects the parent directory /usr under SIP.

My assertion is that Homebrew is using /usr/local incorrectly (and in contravention to all expectation), and that blaming Apple for the problems thereby created is inappropriate.

I also think SIP is a good thing.

The "single user systems aren't the same as server systems" argument cuts both ways. It is also not a big deal to reboot a single-user systems.

I see what you are saying but please step back and take a wider view for a moment.

Even assuming OSX is a single user system (which is arguable), it is 2015 and should that single user be able to accidentally damage /usr/local? I think not, that by today an OS should help protect you from broken postinstall script or what not.

Moreover please think about this: homebrew is not wanting /usr/local/ root:admin but instead /usr/local/ `/usr/bin/whoami`:admin.

Further even on our laptops where there is just one user, I use a non-admin user. I have no problems using FUS, GUI prompted temporary admin permissions, or /usr/bin/login -p and sudo day-to-day, but homebrew has a problem with sudo.

Apple SIP has no problem with /usr/local/ 0:0 but homebrew does. Because of shortcuts homebrew has forced a number of poor decisions on it's users.

Where in FHS does it specify that system and user files should be put in

    /Applications
    /Library
    /Network
    /System
    /User Information
    /Users
    /Volumes

?

FHS does not apply to OSX. Never has, never will.

He's asking because you brought FHS up.

Under B, as an example of standards by another vendor who would be pilloried if they allowed the same lackadaisical approach to preserving system permissions integrity. In response to the comment that Apple was being unreasonable.

Apologies if that was not clear.

There is a standard: http://news.stanford.edu/pr/2015/pr-worms-digest-plastics-09....

This is from RedHat. Not implemented by everyone, but modern OSes (e.g. CoreOS) seem to follow the patterns. CoreOS also do everything in their power to prevent you from mounting /usr as writeable.

Perhaps that doesn't pass your bar for 'real' though since it's not globally implemented ;)

I think that's the wrong link? (It's to a press release from Stanford's engineering department about plastic-eating worms...)

It's been a while since I looked into it, but I opted to stick with MacPorts rather than Homebrew in large part because I got the impression that Homebrew wanted to own /usr/local rather than sharing it with other software. (Maybe that's inaccurate?) I still occasionally compile software by hand rather than through a package manager, and /usr/local has been the default target for a system-wide install on every Unix-style system that I've used in the past 20-ish years.

(Also, my wife and I both have active accounts on my machine, which makes me uneasy having files in a systemwide directory like /usr/local owned by one specific user. That also feels distinctly non-standard to me.)

> I got the impression that Homebrew wanted to own /usr/local rather than sharing it with other software

This is still accurate. Homebrew creates/manages /usr/local/.git. /usr/local/.gitignore starts with /* which is … not conventional.

It is possible to switch /usr/local according to [1], they state it's not recommended though.

[1] https://github.com/Homebrew/homebrew/blob/master/share/doc/h...

I have used ~/.brew for years—it means that I have to do a slightly custom install every time I move to a new machine—but have never had a problem with it.

As others have mentioned, /usr/local may be a fairly standard place to put stuff, but homebrew's permissions model changes the way /usr/local works.

Additionally, /usr/local is used by other applications, and there's no way to ensure that it isn't written over by them or by homebrew when installing or upgrading software.

Putting homebrew in /opt/homebrew means that you can have a systemwide directory that is self-contained, can have a working unix hierarchy underneath and should work.

Putting homebrew in ~/.homebrew/ lets you have a user-specific directory that is self-contained with a hierarchy underneath.

In an ideal world, homebrew would use something like /opt/* for systemwide hierarchy and ~/.homebrew for user-specific hierarchy. We don't live in an ideal world, so we just have to make do with fudges to /usr/local permissions for now.

Unfortunately, /usr/local is a total mess now. There is no internal package management in os x so applications could (and do) overwrite files in /usr/local. These conflicts are very annoying sometimes.

Making/assuming /usr/local is 0777 is definitely not though.

/usr should be Read Only http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

iuguy is not talking about use of /usr/local, but rather the fact that homebrew makes it owned by the user who installed homebrew with permissions so that the user can maintain homebrew packages without sudo. Usually /usr/local is owned by root.

Where am I supposed to put stuff like my shell scripts?

I'm now using /usr/local/bin.

I looked for a guide, no joy. The more opinionated, the better, because I just want to follow the norm.

It is not standard for /usr/local to be writeable by users.

/opt? MacPorts uses /opt/local.

"Fit in with OSX" is why I put it in ~/Library/Homebrew/. Obvs.

What makes you think /usr/local isn't a 'common unix standard'?

Never used Homebrew, but taking ownership of /user/local as I understand it does by default, certainly isn't a 'common unix standard'.

It doesn't take ownership by default IIRC - just recommends that you do so. It will work with sudo if you want to go that way.

I run my Mac with a non-admin account. When I want to install or update Homebrew applications, I su to my admin account and use sudo. Just checked my /usr/local and it's owned by root. I've never had a problem running Homebrew apps from my non-admin account.

That's very clever. There is one problem though, now make clean all install is run as root (well maybe install stages now in homebrew). Imagine an env var not set (the way make vars interact give lots of way to shoot off a big toe here) and the wrong dir gets rm_-rf_-ed or it obliterates something in /bin instead.

If you don't run brew as root you at least protect places like /usr/lib, but you are protected from that and more with macports (where stages and uses nobody).

But for now your approach seems the best pragmatic course to take, thank you for the suggestion.

This sounds like the best suggestion/solution in this thread. But if you run brew from admin, why can't admin take ownership , and run brew without sudo?

So that Homebrew always requires my password to install an app, just like native OS X installs. It also preserves the default permissions. And it's not that hard to sudo.

    > Homebrew always requires my password to install an app

But isn't that _less_ safe?

Instead of trusting Homebrew with /usr/local, you have to trust every formula with `sudo`? Or does it only use sudo for part of it, a `mv` or something?

> certainly isn't a 'common unix standard'

Here I google.com it for you.

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

EDIT: Why is it okay to NOT look up a Standard and be uncertain in your comments when it can be found in 20 seconds tops on the Internet?

Filesystem Hierarchy Standard is a GNU/Linux standard.

'common unix standard' is whatever POSIX states as standard.

I don't see anywhere in there where it says you should take ownership of /usr/local

That is why I said I searched and got the standard for the person who said "certainly it isn't the standard." We have the ultimate resource to know the answer to any question that does have an answer.

I gave this down voted "I googled it for you" because people need to just look up what the Standard is and than speak from a position of knowledge and not some vague non-answer.

For the still lazy the Unix File Hierarchy Standard for /usr

/usr is the second major section of the filesystem. /usr is shareable, read-only data. That means that /usr should be shareable between various FHS-compliant hosts and must not be written to. Any information that is host-specific or varies with time is stored elsewhere.

Large software packages must not use a direct subdirectory under the /usr hierarchy.

Confusingly, it also says:

> The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.

> Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHI...

It says "The /usr/local hierarchy is for use by the system administrator when installing software locally."

That seems to kind of conflict with what you quoted "Large software packages must not use a direct subdirectory under the /usr hierarchy.", unless they mean a vendor-specific directory rather than "/usr/local".

I dunno, all I can say is that in my experience on various unixes, it is a "common unix standard" to install software that is not controlled by the OS package manager to /usr/local. I don't interpret "common unix standard" as "FHS" though -- if you mean FHS, say FHS. To me "common unix standard" just means "something that is commonly done on unix". And installing locally-installed (not using OS distro) software to /usr/local is pretty commonly done, as many people can attest. That's why homebrew chose it, they didn't just make it up.

You are being downvoted because it is a GNU/Linux specific standard, not something that has been adopted by the UNIX standard, POSIX.

And no, I am not the one downvoting you.

Well I feel like an idiot since I absolutely know that but when I was searching I was looking at Unix with no /usr and than went brain dead and thought it was showing /usr as a Linux issue with no standard for /usr. Thank you for correcting me..

As I can't edit the comment, I wasn't referring to the name /usr/local as much as the permissions. It'd make more sense to store systemwide hierarchy in /opt/homebrew/* and user-specific hierarchy in ~/.homebrew/* instead.

Many unix tools are written to build looking for dependencies on default paths including /usr/local.

Putting packages installed in a custom /opt/homebrew location would make it harder to install and use software that often assumes a /usr/local possibility, but not an /opt/homebrew it's never heard of.

It is in fact a pretty common place to put non-distro installed software. And was not (and still is not?) used by OSX out of the box. It made a lot of sense for homebrew to use it.

If I have already installed a bunch of packages, how do I move everything to something like ~/.homebrew? (1) Change the HOMEBREW_PREFIX (2) move the existing aliases from /usr/local/bin (3) add the directory to my path (4) ???