Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

zsh compinit: insecure directories and files on macos catalina when using sudo #680

Open
amuuz74 opened this issue Feb 19, 2020 · 39 comments

Comments

@amuuz74
Copy link

amuuz74 commented Feb 19, 2020

I am using MacOS catalina for a while and always get this REALLY annoying message when I use
sudo zsh

zsh compinit: insecure directories and files, run compaudit for list.
Ignore insecure directories and files and continue [y] or abort compinit [n]?

Is there even a way to avoid this?
Or maybe I should quit using zsh.

In my opinion a shell should be user independent.

@MaximDevoir
Copy link
Contributor

MaximDevoir commented Feb 19, 2020

From ZSHs website on what compaudit does:

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.

This issue sounds similar to #433, where a few methods were proposed to solve the issue. There is also a SO post with a few solutions here.

My guess is zsh thinks potentially dangerous files could be loaded and is, therefore, taking steps to try and prevent that. I'd give the threads above a look to see if any of the solutions work for you based on what files or directories are being designated as insecure when you run compaudit.

@amuuz74
Copy link
Author

amuuz74 commented Feb 19, 2020

@MaximDevoir
Thank you for your answer. I have tried #433 but it won't work. I have also been struggling amount other solutions for weeks.
I don't have this issue with my normal user. It only pops up when I run sudo zsh.
Also, I was using zsh on MacOS before the latest version, it didn't have the problem neither.
I only see this problem on Catalina.

But, still setting ownership to /usr/local/share/zsh does sound strange to me, cause it suppose to be a PUBLIC directory, not only belongs to one account.

Best regards,

@MaximDevoir
Copy link
Contributor

MaximDevoir commented Feb 19, 2020

Yeah, I guess it makes sense for ZSH to complain about insecure files while executing as root; zsh sourcing public/writable files and directories.

You could set the ZSH_DISABLE_COMPFIX flag in your ~/.zshrc config:

ZSH_DISABLE_COMPFIX="true"

From Marc in ohmyzsh/ohmyzsh#6835 (comment):

The way zsh completions are loaded, you will get the message even if there is no real security risk. So just enable [the ZSH_DISABLE_COMPFIX] flag to ignore it.

@pvinis
Copy link

pvinis commented Apr 13, 2020

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

@spacejack
Copy link

spacejack commented Apr 29, 2020

compaudit | xargs chmod g-w

Wow, I just tried this and my Mac instantly rebooted. Now it's stuck in an endless reboot cycle.

I guess that's a lesson in not trying random things one finds online...

UPDATE: Well, after about 2 or 3 dozen restarts, it finally booted. Maybe this was unrelated and just very unlucky timing with entering that command. I had agreed to a software update about an hour or two prior to this, but I find it strange it rebooted exactly as I pressed enter on this command.

Anyway, the "insecure directories" warning is gone now, lol. Mac OS is not my primary OS so I am not used to its peculiarities.

@nandorojo
Copy link

nandorojo commented May 15, 2020

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

This worked for me! Thanks @pvinis

@sjatkins
Copy link

sjatkins commented May 25, 2020

Interesting. In my case I had some homebrew installed stuff is /usr/local/share/zsh directory. When I removed that as zsh is native to MacOS the problem went away. The other solutions above did not work. Anyone know what I will be missing if anything deleting the above. Much of what was complained about were soft links to somewhere in homebrew managed stuff.

I am not sure what initially added these. Something I did over a month ago.

@ty-lerscott
Copy link

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

like @nandorojo, this also solved my problem

@benorgera
Copy link

As my user is the owner of the files which compaudit complains about, I only get the warnings when running as root, ie. after sudo -s. The proposed solutions in #433 all entail changing the owner of files. I want my user to own files in /usr/local/share, but also want to occasionally run things as different users, or root. Why zsh doesn't support this I don't understand. Only solution appears to be to disable compaudit. This is undesirable

@nldoty
Copy link

nldoty commented Jun 11, 2020

@benorgera I have the same issue. My machine has a profile for my own projects, and for my job. ZSH_DISABLE_COMPFIX="true" doesn't fix it for me. I can either have one profile working, or the other.

@Timmy2005
Copy link

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

This worked for me! Thanks @pvinis

Worked for me too

@br3ndonland
Copy link

As my user is the owner of the files which compaudit complains about, I only get the warnings when running as root, ie. after sudo -s. The proposed solutions in #433 all entail changing the owner of files. I want my user to own files in /usr/local/share, but also want to occasionally run things as different users, or root. Why zsh doesn't support this I don't understand. Only solution appears to be to disable compaudit. This is undesirable

I have the same issue. My machine has a profile for my own projects, and for my job. ZSH_DISABLE_COMPFIX="true" doesn't fix it for me. I can either have one profile working, or the other.

@benorgera @nldoty I have a similar situation. I have admin and non-admin user accounts on my macOS work machine. For security purposes (supposedly), I have to do my day-to-day-work with the non-admin account, and only use the admin account for tasks which require those perms, like software upgrades. This means my Zsh installation, and all related directories, are owned by the admin account, and I can't simply chmod and chown to the non-admin account as described in all the other posts.

The solution is to ignore the insecure directories for the non-admin account, as described in the zsh docs and zsh-users/antigen@4c4f805:

# ~/.zshrc
autoload -Uz compinit
if [ "$(whoami)" = "YOUR_NON_ADMIN_USER" ]; then
  compinit -i # Ignore insecure directories
else
  compinit
fi

The non-admin account doesn't have permissions to perform any actions on the pertinent directories, so ignoring them doesn't pose a security risk that I'm aware of.

br3ndonland added a commit to br3ndonland/dotfiles that referenced this issue Jun 20, 2020
Commit c496edb updated the Zsh completion initialization script. This
resulted in an error for non-admin users:

```
zsh compinit: insecure directories and files, run compaudit for list.
```

I have admin and non-admin user accounts on my macOS work machine. For
security purposes (supposedly), I have to do my day-to-day-work with the
non-admin account, and only use the admin account for tasks requiring
those perms, like software upgrades. This means my Zsh installation, and
all related directories, are owned by the admin account, and I can't
simply `chmod` and `chown` to the non-admin account.

The solution is to ignore insecure directories on the non-admin account.

~/.zshrc:

```zsh
autoload -Uz compinit
if [ "$(whoami)" = "brendon.smith" ]; then
  compinit -i # Ignore insecure directories
else
  compinit
fi
```

The non-admin account doesn't have permissions to perform any actions on
the pertinent directories, so ignoring them doesn't pose a security risk
that I'm aware of.

Also see zsh-users/zsh-completions#680.
@alfredomtzg
Copy link

alfredomtzg commented Jul 12, 2020

if you used

ZSH_DISABLE_COMPFIX="true"

the system will not notify you of the insecurities, we just have to change the writing permissions of the group and others depending on the case, go to

cd /usr/local/share/zsh

and put

chmod g-w zsh

or

chmod o-w zsh

@chbrandt
Copy link

I tried to explain what is the (simple) cause for that here: https://stackoverflow.com/a/63447799/687896 , so that we don't start just typing commands we don't really understand what is going on. Basically, ZSH expects system files to be owned and modifiable (w) by either you (the one running the shell) or root.

@mrmarrocos
Copy link

if you used

ZSH_DISABLE_COMPFIX="true"

the system will not notify you of the insecurities, we just have to change the writing permissions of the group and others depending on the case, go to

cd /usr/local/share/zsh

and put

chmod g-w zsh

or

chmod o-w zsh

This worked for me! Thanks!

@hchanenator
Copy link

Adding ZSH_DISABLE_COMPFIX="true" to my .zshrc worked to suppress the messages for me.

@webbp
Copy link

webbp commented Oct 1, 2020

Adding ZSH_DISABLE_COMPFIX="true" to my .zshrc did not work for me.

Here are working options:

  1. don't use homebrew because it breaks permissions and installs files in /usr/local (but i can't do that because i need a package not available in macports)

  2. undo the damage homebrew did to /usr/local/share/zsh (btw, i didn't want homebrew for anything to do with my zsh and it never asked permission)

sudo rm -rf /usr/local/share/zsh/site-functions
sudo chown root:admin rm -rf /usr/local/share/zsh
sudo chmod g-w /usr/local/share/zsh

@Vlad412
Copy link

Vlad412 commented Oct 3, 2020

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

Thanks man, I had this issue after installing nvm

@abstractmachines
Copy link

Just using ZSH_DISABLE_COMPFIX="true" worked for me in .zshrc, also apologies, didn't mean to link here with a PR. Sorry about that/pls ignore.

@92EPk
Copy link

92EPk commented Oct 24, 2020

I used compaudit | xargs chmod g-w and it worked.

it worked, thanks!

br3ndonland added a commit to br3ndonland/dotfiles that referenced this issue Nov 6, 2020
Commit c496edb updated the Zsh completion initialization script. This
resulted in an error for non-admin users:

```
zsh compinit: insecure directories and files, run compaudit for list.
```

I have admin and non-admin user accounts on my macOS work machine. For
security purposes (supposedly), I have to do my day-to-day-work with the
non-admin account, and only use the admin account for tasks requiring
those perms, like software upgrades. This means my Zsh installation, and
all related directories, are owned by the admin account, and I can't
simply `chmod` and `chown` to the non-admin account.

The solution is to ignore insecure directories on the non-admin account.

~/.zshrc:

```zsh
autoload -Uz compinit
if [ "$(whoami)" = "brendon.smith" ]; then
  compinit -i # Ignore insecure directories
else
  compinit
fi
```

The non-admin account doesn't have permissions to perform any actions on
the pertinent directories, so ignoring them doesn't pose a security risk
that I'm aware of.

Also see zsh-users/zsh-completions#680.
@daniborgs
Copy link

I tried to explain what is the (simple) cause for that here: https://stackoverflow.com/a/63447799/687896 , so that we don't start just typing commands we don't really understand what is going on. Basically, ZSH expects system files to be owned and modifiable (w) by either you (the one running the shell) or root.

Read what chbrandt commented on 22 Aug

@gremz
Copy link

gremz commented Dec 2, 2020

Interesting. In my case I had some homebrew installed stuff is /usr/local/share/zsh directory. When I removed that as zsh is native to MacOS the problem went away. The other solutions above did not work. Anyone know what I will be missing if anything deleting the above. Much of what was complained about were soft links to somewhere in homebrew managed stuff.

I am not sure what initially added these. Something I did over a month ago.

homebrew sets up these files to be used for shell completions. Take a look at https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh to fix this.

@777uliahshafar
Copy link

It just work, by the way I come to this problem because I have reinstalled npm and install using nvm MacOS. That's great.

@minierparedes
Copy link

The issue with Hombrew and Catalina, re-installing npm via NVM still persist. the command compaudit | xargs chmod g-w was the best method that worked for my system.

@torgeir
Copy link

torgeir commented Jan 25, 2021

compaudit | xargs chmod g-w worked for me on big sur.

@Ricemilk1122
Copy link

Yeah, I guess it makes sense for ZSH to complain about insecure files while executing as root; zsh sourcing public/writable files and directories.

You could set the ZSH_DISABLE_COMPFIX flag in your ~/.zshrc config:

ZSH_DISABLE_COMPFIX="true"

From Marc in ohmyzsh/ohmyzsh#6835 (comment):

The way zsh completions are loaded, you will get the message even if there is no real security risk. So just enable [the ZSH_DISABLE_COMPFIX] flag to ignore it.

this config is helpful for me.thank you!

@tcoliver
Copy link

Is there any issue with just removing write permissions for group from the directory (i.e., chmod -R 755 /usr/local/share/zsh)? Seemed to work well for me.

@doboy
Copy link

doboy commented Feb 28, 2021

For me, some of the files were symlinks so I had to follow the symlink and update their permissions accordingly

@josh-sea
Copy link

josh-sea commented Apr 7, 2021

compaudit | xargs chmod g-w

Wow, I just tried this and my Mac instantly rebooted. Now it's stuck in an endless reboot cycle.

I guess that's a lesson in not trying random things one finds online...

UPDATE: Well, after about 2 or 3 dozen restarts, it finally booted. Maybe this was unrelated and just very unlucky timing with entering that command. I had agreed to a software update about an hour or two prior to this, but I find it strange it rebooted exactly as I pressed enter on this command.

Anyway, the "insecure directories" warning is gone now, lol. Mac OS is not my primary OS so I am not used to its peculiarities.

oh-my-zsh mentioned some potential issues with write access for the group and others, prob for security reasons. Below is the message I was getting.

I cd to the directory oh-my-zsh mentioned as potentially insecure and applied the compaudit line it provided and it worked fine, so far.

$ compaudit | xargs chmod g-w,o-w

Here is what oh-my-zsh printed to terminal:

[oh-my-zsh] For safety, we will not load completions from these directories until
[oh-my-zsh] you fix their permissions and ownership and restart zsh.
[oh-my-zsh] See the above list for directories with group or other writability.

[oh-my-zsh] To fix your permissions you can do so by disabling
[oh-my-zsh] the write permission of "group" and "others" and making sure that the
[oh-my-zsh] owner of these directories is either root or your current user.
[oh-my-zsh] The following command may help:
[oh-my-zsh] compaudit | xargs chmod g-w,o-w

[oh-my-zsh] If the above didn't help or you want to skip the verification of
[oh-my-zsh] insecure directories you can set the variable ZSH_DISABLE_COMPFIX to
[oh-my-zsh] "true" before oh-my-zsh is sourced in your zshrc file.

@sergiofdomingues
Copy link

sergiofdomingues commented Apr 12, 2021

compaudit | xargs chmod g-w worked for me on big sur.

Yep, nothing else worked for me. Thanks.

@cfurst
Copy link

cfurst commented May 14, 2021

compaudit | xargs chmod g-w

Wow, I just tried this and my Mac instantly rebooted. Now it's stuck in an endless reboot cycle.

I guess that's a lesson in not trying random things one finds online...

UPDATE: Well, after about 2 or 3 dozen restarts, it finally booted. Maybe this was unrelated and just very unlucky timing with entering that command. I had agreed to a software update about an hour or two prior to this, but I find it strange it rebooted exactly as I pressed enter on this command.

Anyway, the "insecure directories" warning is gone now, lol. Mac OS is not my primary OS so I am not used to its peculiarities.

Wow... what were the directories? Were they homebrew related like /usr/local/share ??

@dexiouz
Copy link

dexiouz commented Jun 10, 2021

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

Wonderful. This worked for me

@sammyloto
Copy link

I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.

Thanks a lot, this fixed the issue on Big Sur.

@ikyhtr
Copy link

ikyhtr commented Aug 3, 2021

In my case, running chmod 755 /paths/listed/by/compaudit/ fixed it. That's all.

@betoflakes
Copy link

In my case, running chmod 755 /paths/listed/by/compaudit/ fixed it. That's all.

this works perfect, thanks @strongkyomu

@msva
Copy link
Contributor

msva commented Sep 22, 2023

for all those who performing chmod on random paths on the filesystem without full understanding what EXACTLY they are doing:

Please, consider that you have been warned, that you performing potentially harmful action, that can (but not necessary will, or not necessary right now) brake your system (or anything else) and/or may lead to your device being hacked

@TruncatedDinoSour
Copy link

for all those who performing chmod on random paths on the filesystem without full understanding what EXACTLY they are doing:

Please, consider that you have been warned, that you performing potentially harmful action, that can (but not necessary will, or not necessary right now) brake your system (or anything else) and/or may lead to your device being hacked

bro at worst what could happen if u chmod 755 <d> is other users being able to read and enter directories ( not even their content, just list the files and cd into them ), even then if its not any core files it rarely causes any issues ( some programs check for perms and stuff can break ( e.g. sudo with the sudoers file, iirc it has to be 440 or smt idr ) )

@msva
Copy link
Contributor

msva commented Sep 26, 2023

worst what could happen <...> other users being able to read and enter directories

  1. some times this can be enough for some attack vectors.
  2. well. That was not onl about 755, but in general. If they continue to behave same way, they may someday execute chmod 777. And even on root folder.
  3. actually, by "break some things" I also meant situations, when some software can stop wotking because of "insecure permissions" by their mean.

@dmuiX
Copy link

dmuiX commented Nov 22, 2023

Came from google and use zsh on debian.
On this system setting ZSH_DISABLE_COMPFIX=true did not change anythind. I needed to set compinit -u as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests