By default /usr/local does not exist on fresh installs of OS X 10.5 to 10.10.
When upgrading from Yosemite (without the /usr/local directory) to El Capitan, /usr/local is created automatically, I checked. So then there should be no problem at all.
There might be a bug in the El Capitan installer when upgrading from earlier systems or it could be related to my system.
osxfuse and libdvdcss are not in /System, they never have been. /usr/local is a perfectly valid location to install shared libraries to. That’s why Apple specifically whitelisted it in El Capitan.
/usr was updated during the update process
but /usr/local was last updated over a month ago… not that means anything specific since /usr/local is also empty
but /usr/bin, /usr/sbin, /usr/lib, /usr/libexec and /usr/share were also updated during the timeframe of the upgrade process
And yet Marcus’ cousin’s machine apparently did not have it, and one can find plenty of stuff on the internet indicating that it is not always present in all Mac OS X installs…
We have a project that puts some stuff in /usr/local/share. If that directory (or any of its ancestors) is missing, it creates the missing directories as needed. It seems to me that under El Capitan, our only option will be to tell the user to turn off SIP if any of those directories don’t exist since the OS will not allow us to create them with SIP on.
What’s not clear to me is how often this might come up. Hopefully it’s a rare occurrence…
[quote=217262:@Peter Truskier]And yet Marcus’ cousin’s machine apparently did not have it, and one can find plenty of stuff on the internet indicating that it is not always present in all Mac OS X installs…
We have a project that puts some stuff in /usr/local/share. If that directory (or any of its ancestors) is missing, it creates the missing directories as needed. It seems to me that under El Capitan, our only option will be to tell the user to turn off SIP if any of those directories don’t exist since the OS will not allow us to create them with SIP on.
What’s not clear to me is how often this might come up. Hopefully it’s a rare occurrence…[/quote]
Maybe it is time to consider using Apple Installer. It executes with the privileges necessary to create the required directories if needed.
If you’re not use PackageMaker (or its Xcode/CLI equivalent) to install, you will be very upset with the number of calls you’ll be receiving once El Capitan hits the desktops.
Apple’s taken things to the extreme with this update. They have now “blessed” all of the core Unix locations, so nothing into /bin, /usr/bin, /sbin, /usr/sbin, /etc, /usr/share, /lib, /usr/lib, /, and /System at least. Additionally, /Library and /usr/local - while approved - still need to be managed by elevated privileges.
I filed my disagreement back when I first learned of SIP (Supremely Irritating Permissions), and while they responded that they were still in discussion about the final functionality involved, it looks like nothing changed between then and now.
In fact, you may find that you can’t even disable SIP in the release.
Not from within the OS, but you can reboot into the recovery partition to reset it. If it were possible to change from within the OS, it would defeat the point to a degree.
Here it’s a workaround to get rid of the new SIP (System Integrity Protection) disallowing modifications to some critical system locations.
Reboot into recovery mode (reboot and hold down Cmd-R)
Open a terminal
Use this command: csrutil disable
Reboot and do what you need in /usr or other system locations
When you’re done, it is highly recommended that you re-enable SIP by following the same steps, but using csrutil enable in step 3.
I think this is much ado about nothing since being able to write into /usr/local/bin and /usr/local/lib can be just as damning since Apple defaults /usr/local/bin to the front of the PATH variable. Plus, I’ve already been on the phone with 4 major studios this morning and the first thing that they do after the install is the csrutil change - and they have no intention of setting it back to enabled. All I see this “feature” doing is adding a layer of confusion for users who use their Mac systems for more than Kindle and playing movies.
Okay @Markus Winter, I’ll bite - why do you strongly disagree? If I can park malware into /usr/local/bin that looks like “vim”, and /usr/local/bin is first in your path, and you go and startup vim to “hopefully” edit a file, and my malware installs a keystroke monitor that is also tucked into /usr/local/bin, …
As much as some of us (including yours truly) like going deep into the belly of the beast, I can understand why Apple sanctuarizes strategic Unix system directories. Mac OS X is probably one of the safest OSses available, but the underlying Unix can be attacked by the same people who do their best to develop malware for Linux.
SIP is an excellent way of insuring that Mac OS X remains safe.
IMHO Package Maker or other Apple sanctioned installer is the only way to insure a smooth ride for users as well as developers. As far as I can tell, all software that really need to do under the hood stuff in the system, would that be Fuse for OS X at http://osxfuse.github.io/ which the latest version dates back Sept. 25 and should support El Capitan, or antiviruses, do not require surgery. They provide an installer.
Copying directly into system directories looks very much in the clean world of contemporary Mac OS X like a hacker’s proposition…