/usr/local permission change

[DBrowning]

Is there anything in the jamf binary that would be resetting permission on the /usr/local/bin or /usr/local/share folders? Had a developer come up today reporting that when he runs home brew its failing because /usr/local/bin and /usr/local/share folders are owned by root. He changes ownership to him self so that his local environment can work and at somepoint the owner gets changed back root.

[bentoms]

@ddcdennisb not AFAIK. What OS? Deploying any packages to those locations?

[DBrowning]

10.10.5. I am not pushing any apps to that folder. Home brew uses /usr/local

[thoule]

He changes ownership to him self

Yeah- that's a bad idea. I suspect that the weekly or daily run scripts from Mac OS are fixing it. Because he's breaking it. Because its a bad idea.

[mm2270]

@thoule wrote:

Yeah- that's a bad idea. I suspect that the weekly or daily run scripts from Mac OS are fixing it. Because he's breaking it. Because its a bad idea.

I've actually seen at least one case over the last few years where a user essentially borked their whole Mac because they ran a recursive sudo ownership change across the whole OS to make themselves the owner of... everything, because, well, he just thought he needed to. Yikes! True story. As you can imagine, the OS does not deal with that too well. (at least 10.11 will put a stop to this)
Bottom line is, sometimes the 'nix crowd are their own worst enemies when they come to the platform. OS X ≠ straight Unix. Yes, its based on it, but there are still some significant differences that some of them just don't get.

[DBrowning]

With HomeBrew it tells users to chown the /usr/local/bin and /usr/local/share folders so that it can work. This hasn't been an issue until about a month ago. just happens that I upgraded my JSS to 9.81 a little over a month ago. So either Apple is getting sneaky and starting to change the permission back after OS upgrades or something else is going on.

We have about 400 Devs that have been running this setup for over 5 years and its never been an issue. I worked with one of them today and attempted just doing a chmod and will see what happens.

[davidacland]

Generally speaking, you're not supposed to mess around with system folders in OS X, particularly changing ownership, permissions, renaming, moving, deleting etc. OS updates will certainly trample over the changes but as @thoule mentioned, if its "correcting" itself more often, its possibly the daily / weekly scripts.

Would be better to adjust whatever home brew needs to run than the OS IMHO.

[thoule]

@ddcdennisb

HomeBrew it tells users to chown the /usr/local/bin and /usr/local/share folders

A quick search and I didn't see anything that said that. Can you tell me where that information came from? If true, I'd really like to know what's going on.

[htse]

is it possible it may have been effect of last week's OS X updates?

[DBrowning]

@thoule i've attached the screenshot from when first installing homebrew. it shows that just to install the software it will change ownership of the folders.

if users are having issues with homebrew running, they run the command "brew doctor" and are given the following messages:

[emily]

One of our teams uses homebrew and the fix was relatively simple and a developer sent me this link:

https://github.com/Homebrew/homebrew/blob/master/share/doc/homebrew/El_Capitan_and_Homebrew.md

I'm admittedly not sure if this is best practice or causes other issues… I guess I'll find out later when said developer potentially has issues down the road.

[calumhunter]

+1 homebrew is 'doing it wrong' or it is not being installed correctly

/usr/local

Should be owned by root:wheel

Its a system wide folder for all users to place 3rd party binaries/applications/config items ect ect

Perhaps running the installer for homebrew with sudo is the correct way to install it?

That way the installer for homebrew runs as root and has write access to those folders.

I don't use homebrew so I might be wrong, but that seems to make more sense, I mean you don't install applications on OS X as a user do you? Installer prompts for admin creds which then installs the applications as root:wheel into /Applications

[DBrowning]

@calumhunter

I remember one of the devs saying something about not running the installer with sudo but can't remember the reasoning behind it. I'll follow up on that.

[DBrowning]

found this in homebrew's FAQ.... kinda comical.....

Why does Homebrew say sudo is bad?

tl;dr Sudo is dangerous, and you installed TextMate.app without sudo anyway.

Homebrew is designed to work without using sudo. You can decide to use it but we strongly recommend not to do so. If you have used sudo and run into a bug then it is likely to be the cause. Please don’t file a bug report unless you can reproduce it after reinstalling Homebrew from scratch without using sudo.

You should only ever sudo a tool you trust. Of course, you can trust Homebrew ;) But do you trust the multi-megabyte Makefile that Homebrew runs? Developers often understand C++ far better than they understand make syntax. It’s too high a risk to sudo such stuff. It could break your base system, or alter it subtly.

[thoule]

@ddcdennisb That's hilarious! "sudo is dangerous. don't use it. Instead give ownership of all system directories to homebrew to modify directly without sudo because clearly that's safe!" Yeah- no more homebrew in my office.

[mm2270]

The missing piece to the above FAQ-

So instead of using sudo, we'll have you modify the permissions on folders created by the OS and make you the owner, creating a security risk in the process (and only to have a repair permissions process put it back the way it should be later).

Yeah, that makes perfect sense. Not sure who wrote that up for homebrew, but they are delusional. Folders created by the OS should not be touched or have permissions modified. That's the entire reason Repair Permissions even exists in OS X, and why Apple effectively put an end to it with El Capitan. (Repair Permissions is MIA in the 10.11 version of Disk Utility you'll notice) Its also why sudo commands exist! So you don't have to change the actual permissions to be able to add items into protected locations. Good grief!

To put this into perspective, making you the owner of /usr/local/ is the equivalent of needing to make you the owner of /Applications/ just because you installed a new application into that folder that didn't come with OS X. Yep, its just as nuts.

[amazonClientSys]

FYI..
Homebrew's recommendation to recursively change ownership of /usr/local using the following command breaks jamfAgent which leads to a broken Self Service.

sudo chown -R $(whoami):admin /usr/local

This will fix it

sudo chown -R root:wheel /usr/local/jamf

[mario]

To add some signal, we've had a few users report this same issue, and it appears to be triggered by Sophos Anti-Virus:

https://community.sophos.com/products/free-antivirus-tools-for-desktops/f/17/t/10029

Sophos says they'll update the client in the next few weeks to stop chown-ing /usr/local. That said, I may start installing Homebrew in a different path so it isn't affected by issues like this down the road, since as others have mentioned, Apple may also opt to reset permissions during future software updates.