Seperate Admin User Viable with zsh and brew?


(Elias Rohrer) #1

Hello,
I did a fresh install of my laptop and decided on having a separate administrator account this time. However, this is not as easy as expected.
I installed Homebrew to /usr/local with this admin account and then added /usr/local to the path of my standard user.
However, when I started zsh as my standard user, it started to complain about “insecure directories”. It does so, since it checks for safe permissions on the loaded completion files and sees that they belong to another user (my admin user). Following a post on SO, this can only be circumvented by calling chmod 755 and chown root:staff on the directories in question, which indeed did the trick for me.
However, this meant that I also had to transfer permissions of /usr/local/share to root:staff — and of course, now brew is complaining.

I’m open for suggestions how to fix this for both sides (zsh and brew)! However, right now it seems to me the only solution is to revert back to a single account with administrative privilege, which is clearly less secure than using two accounts — and this surely is not the idea of the security measures introduced by zsh or brew.


(Mike McQuaid) #2

Homebrew is meant (and designed and supported) to be run as your main administrative user. We use the MacOS sandbox (the same as applications from the Mac App Store) so you don’t need to worry about installations writing where they shouldn’t do. If you’re unable to figure this out alone I recommend you use an admin user as your main and Homebrew user.


(Elias Rohrer) #3

I’m running homebrew as my main administrative user. However, it should be possible to use the software it installs as every other standard user, no?
I’m not worried about Homebrew writing somewhere—but other applications may do so. Therefore, I don’t want to run everything as an admin user for day-to-day work.

So, do I really only have the options of
a) Dismissing the zsh complaints every time I start a shell
b) Migrate to a single administrative user for administrative tasks and day-to-day work
c) Chown the directories to root and run homebrew via sudo, which is also not supported?

Hum, to be honest, I find each of these options unsatisfactory.

Additionally, if Homebrew runs in a sandbox, why is running it via sudo discouraged? Wouldn’t installation scripts run in the sandbox, too?


(Mike McQuaid) #4

It may be possible but it’s unsupported.

Additionally, if Homebrew runs in a sandbox, why is running it via sudo discouraged? Wouldn’t installation scripts run in the sandbox, too?

The sandbox does not work for the root user, unfortunately. As a result it’s extremely dangerous to use it there (which is why it was disabled).


(Elias Rohrer) #5

I see. I think I found a temporary work-around for this specific problem: copying zsh-completions and the respective site-function scripts (e.g. for brew or youtube-dl) to a folder owned by my standard user.
Then, zsh won’t complain and load the scripts. However, I have to keep them up-to-date manually now.

I hope I won’t run into more problems with this setup…


(Mike McQuaid) #6

I hope so too but just to warn you: you may well do and we’ll be unable to help you.


(Zhiming Wang) #7

Following a post on SO, this can only be circumvented by calling chmod 755 and chown root:staff on the directories in question.

No offense, but SO offers wrong answers or bad suggestions very often, even when said answers have hundreds of upvotes from equally confused users. (I say this as someone who was once active in the bash and zsh tags, and later left due to the low quality of questions.) In this case chmod -R 755 on /usr/local/share/zsh/site-functions is both ridiculously wrong and useless (unless the guy somehow screwed up permissions with e.g. chmod -R 777 in the first place; even then zsh functions shouldn’t be executable).

What you should do instead is read the manual http://zsh.sourceforge.net/Doc/Release/Completion-System.html, which is very clear on this issue:

For security reasons compinit also checks if the completion system would use files not owned by root or by the current user, or files in directories that are world- or group-writable or that are not owned by root or by the current user. If such files or directories are found, compinit will ask if the completion system should really be used. To avoid these tests and make all files found be used without asking, use the option -u, and to make compinit silently ignore all insecure files and directories use the option -i. This security check is skipped entirely when the -C option is given.

As you can see, world- or group-writability isn’t a problem here unless you have messed with it. The problem is /usr/local/share/zsh/site-functions and files in it needs to be owned by your standard user or root to pass the security check. Since both would be a pain to use with Homebrew, you’re left with the option compinit -u. This is generally not recommended, but if you’re the only one that’s ever going to touch your computer, or the admin account, it should be fine. (But don’t hold me accountable if you’re ever hacked.)

However, it should be possible to use the software it installs as every other standard user, no?

The problem is the discrepancy between Homebrew’s trust model and zsh’s (or that of most standard Unix software). Homebrew reserves root for only a handful of things that are absolutely necessary (as it recognizes the danger of installing arbitrary software as root), and uses the admin account for things that are somewhat risky; standard Unix software only trusts root, and assumes that sudoers who install stuff as root has audited every piece of software (which in practice is of course untrue).

P.S. Those who recommend chmod/chown with the -R flag for whatever reason without a YUGE warning flag should be held accountable. It’s on the same level as rm -rf /.