zsh compinit: insecure directories and files on macos catalina when using sudo
amuuz74 opened this issue · comments
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.
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.
@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,
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.
I used compaudit | xargs chmod g-w and it worked. For some reason the ZSH_DISABLE_COMPFIX="true" wouldn't fix it.
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.
I used
compaudit | xargs chmod g-wand it worked. For some reason theZSH_DISABLE_COMPFIX="true"wouldn't fix it.
This worked for me! Thanks @pvinis
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.
I used
compaudit | xargs chmod g-wand it worked. For some reason theZSH_DISABLE_COMPFIX="true"wouldn't fix it.
like @nandorojo, this also solved my problem
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
@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.
I used
compaudit | xargs chmod g-wand it worked. For some reason theZSH_DISABLE_COMPFIX="true"wouldn't fix it.This worked for me! Thanks @pvinis
Worked for me too
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
fiThe 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.
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
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.
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!
Adding ZSH_DISABLE_COMPFIX="true" to my .zshrc worked to suppress the messages for me.
Adding ZSH_DISABLE_COMPFIX="true" to my .zshrc did not work for me.
Here are working options:
-
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)
-
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
I used
compaudit | xargs chmod g-wand it worked. For some reason theZSH_DISABLE_COMPFIX="true"wouldn't fix it.
Thanks man, I had this issue after installing nvm
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.
I used
compaudit | xargs chmod g-wand it worked.
it worked, thanks!
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
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.
It just work, by the way I come to this problem because I have reinstalled npm and install using nvm MacOS. That's great.
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.
compaudit | xargs chmod g-w worked for me on big sur.
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_COMPFIXflag in your~/.zshrcconfig: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!
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.
For me, some of the files were symlinks so I had to follow the symlink and update their permissions accordingly
compaudit | xargs chmod g-wWow, 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.
compaudit | xargs chmod g-wworked for me on big sur.
Yep, nothing else worked for me. Thanks.
compaudit | xargs chmod g-wWow, 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 ??
I used
compaudit | xargs chmod g-wand it worked. For some reason theZSH_DISABLE_COMPFIX="true"wouldn't fix it.
Wonderful. This worked for me
I used
compaudit | xargs chmod g-wand it worked. For some reason theZSH_DISABLE_COMPFIX="true"wouldn't fix it.
Thanks a lot, this fixed the issue on Big Sur.
In my case, running chmod 755 /paths/listed/by/compaudit/ fixed it. That's all.
In my case, running
chmod 755 /paths/listed/by/compaudit/fixed it. That's all.
this works perfect, thanks @strongkyomu
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
for all those who performing
chmodon 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 ) )
worst what could happen <...> other users being able to read and enter directories
- some times this can be enough for some attack vectors.
- 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. - actually, by "break some things" I also meant situations, when some software can stop wotking because of "insecure permissions" by their mean.
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.