zsh sudo -s gives "insecure directories and files" error #7801
Comments
|
What perms should they have? |
|
I'm mystified! I don't know what compaudit thinks is insecure; from what I've read, it looks for group-writable dirs, but as you can see, nothing in the path is group-writable. |
|
I just came across the same issue: When loggin in I get the message: The reason was that I used a different user to install zsh. When the /usr/local/Cellar/zsh folder belongs to me (I uninstalled zsh and reinstalled it with my user) the message disappears. |
|
Also, I noticed that this error appears when the rights are not 755, but 775. |
|
@rweng: I think you're seeing the same symptom with a different root cause; in my case, /usr/local/Cellar/zsh/** is all owned by the user "jay", and normal logins don't see the error - I only get it when sudo'ing to root, and I suspect it's that zsh really wants to be owned by root, while homebrew really wants things to be owned by the user. Now that you've fixed the ownership, do you see the error when you do "sudo -s"? |
|
yes, I do |
|
Not sure there's anything that Homebrew can or should do here. |
|
I think @jacknagel is right. The fix for this is to add the "-u" flag when you call compinit; this uses all directories found by compaudit, whether or not they pass security checks. I don't think homebrew installs any default .zshrc, which is where you'd do this.. if someone can confirm that, we should close this. |
That's correct, closing. |
…gacy-homebrew#7801: added -u flag to compinit to load insecure directories/files
For some reason, zshcompsys thinks that it is up to it do be a sysadmin. By default, `compinit` checks for 'insecure' directories and files. From `man 1 zshcompsys`: 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. People suffering from the rammifications of this can be found here: http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/ http://stackoverflow.com/questions/13762280/zsh-compinit-insecure-directories http://www.zsh.org/mla/users/2008/msg00566.html Homebrew/legacy-homebrew#7801 To sumarize, if you have files with permissions that are 'bad' (ex: 777 on /usr/share/folder/), then zshcompsys enables you to ignore those directories and files. That begs the question, why is it zshcompsys' job to police the system? If you have 777 permissions on a folder in /usr/share/something, that makes the sysadmin DUMB. On the flip side, there are many situations in which it is perfectly legitimate to allow a group to have write permissions to a directory that contains binary files. It shouldn't be up to zshcompsys to point out that you're an idiot. Running compaudit (the 'security' checks) also takes up a significant chunk of time, which can be exacerbated on low-end systems. This commit disables the compaudit, while still enabling the .zcompdump as provided by compinit, as it acts as a cache.
For some reason, zshcompsys thinks that it is up to it do be a sysadmin. By default, `compinit` checks for 'insecure' directories and files. From `man 1 zshcompsys`: 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. People suffering from the rammifications of this can be found here: http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/ http://stackoverflow.com/questions/13762280/zsh-compinit-insecure-directories http://www.zsh.org/mla/users/2008/msg00566.html Homebrew/legacy-homebrew#7801 To sumarize, if you have files with permissions that are 'bad' (ex: 777 on /usr/share/folder/), then zshcompsys enables you to ignore those directories and files. That begs the question, why is it zshcompsys' job to police the system? If you have 777 permissions on a folder in /usr/share/something, that makes the sysadmin DUMB. On the flip side, there are many situations in which it is perfectly legitimate to allow a group to have write permissions to a directory that contains binary files. It shouldn't be up to zshcompsys to point out that you're an idiot. Running compaudit (the 'security' checks) also takes up a significant chunk of time, which can be exacerbated on low-end systems. This commit disables the compaudit, while still enabling the .zcompdump as provided by compinit, as it acts as a cache.
The text was updated successfully, but these errors were encountered: