Zplug: Compinit with zsh, zplug from Homebrew in multi-user setup

[felixjung]

• Type:
  
  
  
  • [x] Bug
  
  
  • [ ] Enhancement
  
  
  • [ ] Feature Request
  
  
  • [x] Question
  
  

---

• zplug --version: 2.4.1
• zsh --version: 5.3.1
• uname -a: Darwin Tarkin-2.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64

Minimal zshrc (with less than 30 lines)

Create a minimal reproducing set of configurations for this issue. Please remove all unnecessary parts!

source ~/.zplug/init.zsh

if zplug check || zplug install; then
  zplug load --verbose
fi

Step to reproduce

1. Install zsh and (optionally) zplug via Homebrew.
2. You need to be on a Mac with multiple user accounts (for example a work and a personal account).
3. Launch zsh. zplug will load and run compinit without the -u flag, causing an insecure directories warning to show -- always.

Description

In the above setup, I can't find a way to not have compinit yell at me for insecure directories. If you run Homebrew you have to set the owner of at least some directories under /user/local to one of your two accounts or potentially to a third account that's used exclusively for Homebrew operations. In this case whenever you're launching zsh on an account other than the "Homebrew owner" account, compinit will complain about insecure directories. I've seen a PR that tries to address this for when you are in working with sudo (#396).

Do you have a recommended approach for addressing this issue? Otherwise, could we add some kind of override that, when active, will always run compinit -u?

Thanks!

[jsmestad]

@felixjung I hit this as well on one of my machines. To fix it, its pretty simple. You need to make the zsh directories non-writable.

Run compaudit in a shell. It will list out the offending directories. For me I had to run the following for 2 directories:

chmod g-w /usr/local/share/zsh/site-functions
chmod g-w /usr/local/share/zsh

[felixjung]

Thanks @jsmestad. I'm luckily no longer running two users on one machine 😅 Not sure if this would have also worked in my case.

[g0t4]

compinit will gripe under two conditions:

• the current user OR root doesn't own the files
• the files are group writable

This means in a multi-user setup:

• the user that owns files in /usr/local will be fine (assuming the files are not group writable)
• the user that doesn't own the files will never be fine because the files would need to be owned by root and brew will not allow that

So we really need a way to pass -i/-u to fix this issue for secondary accounts. As it currently is it seems zplug will always gripe on secondary users if using brew to install zsh.

[kevinjalbert]

I'm hitting this issue as well (multi-user). Right now I've just patched how compinit is used in zplug to include the -u option. Not the greatest but it works given that I couldn't find any way to make this work given my situation.

[benwoodward]

I ran into this issue too, (using Homebrew with multi-user directory permissions) took me a while to figure out what was causing it. Ran ag compinit on all relevant directories to locate the line that was invoking compinit.

For anyone else with this problem you need to make the following change to /usr/local/opt/zplug/base/core/load.zsh

https://github.com/zplug/zplug/blob/fdc2bf46a6cc29430b947362f20d3a643edc0f3a/base/core/load.zsh#L34

diff --git a/load.zsh b/load.zsh
--- a/load.zsh
+++ b/load.zsh
@@ -1,34 +1,34 @@
-compinit -d "$ZPLUG_HOME/zcompdump"
+compinit -u -d "$ZPLUG_HOME/zcompdump"

[benorgera]

Has any progress been made on this? Just switched from bash to zsh and am being plagued by ownership of files in /usr/local/share when switching between accounts. As is the only options appear to be to disable compfix, or hack around as was proposed above (I don't wish to change ownership of files).

Can someone explain what compfix actually does and what are the implications of disabling? Ideally zsh would support multiple users out of the box, I am surprised there is so much chatter about this issue but only real fix is disabling a feature.

[windware-ono]

What is the implication of applying the -u fix as 2 posts above? That fixes it for me.

Without a fix, whenever I log in, I always get prompted with 'y/n' and if I type a command without answering it, obviously the first letter gets consumed and gets answered as 'n' unless the first letter was 'y' causing all the file completions to fail in that session.