This repository has been archived by the owner. It is now read-only.

zsh sudo -s gives "insecure directories and files" error #7801

Closed
jaylevitt opened this Issue Sep 24, 2011 · 9 comments

Comments

Projects
None yet
4 participants
@jaylevitt
Copy link
Contributor

jaylevitt commented Sep 24, 2011

~% zsh --version
zsh 4.3.12 (i386-apple-darwin10.8.0)

~% sudo -s

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

~# compaudit | head
There are insecure directories and files:
/usr/local/Cellar/zsh/4.3.12/share/zsh/site-functions
/usr/local/Cellar/zsh/4.3.12/share/zsh/functions
/usr/local/Cellar/zsh/4.3.12/share/zsh
/usr/local/Cellar/zsh/4.3.12/share/zsh
/usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_a2ps
/usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_a2utils
/usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_aap
/usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_acpi
/usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_acpitool
/usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_acroread


~# ls -ld /usr /usr/local /usr/local/Cellar /usr/local/Cellar/zsh /usr/local/Cellar/zsh/4.3.12 /usr/local/Cellar/zsh/4.3.12/share /usr/local/Cellar/zsh/4.3.12/share /usr/local/Cellar/zsh/4.3.12/share/zsh /usr/local/Cellar/zsh/4.3.12/share/zsh/functions /usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_a2ps
drwxr-xr-x@  18 root  wheel   612B Feb 19  2011 /usr/
drwxr-xr-x   20 jay   staff   680B Sep 24 11:57 /usr/local/
drwxr-xr-x   26 jay   staff   884B Sep 24 12:20 /usr/local/Cellar/
drwxr-xr-x    4 jay   staff   136B Sep 24 12:31 /usr/local/Cellar/zsh/
drwxr-xr-x    8 jay   staff   272B Sep 24 12:32 /usr/local/Cellar/zsh/4.3.12/
drwxr-xr-x    4 jay   staff   136B Sep 24 12:32 /usr/local/Cellar/zsh/4.3.12/share/
drwxr-xr-x    4 jay   staff   136B Sep 24 12:32 /usr/local/Cellar/zsh/4.3.12/share/
drwxr-xr-x    5 jay   staff   170B Sep 24 12:32 /usr/local/Cellar/zsh/4.3.12/share/zsh/
drwxr-xr-x  863 jay   staff    29K Sep 24 12:32 /usr/local/Cellar/zsh/4.3.12/share/zsh/functions/
-rw-r--r--    1 jay   staff   2.7K Sep 24 12:32 /usr/local/Cellar/zsh/4.3.12/share/zsh/functions/_a2ps
~% 
@adamv

This comment has been minimized.

Copy link
Contributor

adamv commented Sep 24, 2011

What perms should they have?

@jaylevitt

This comment has been minimized.

Copy link
Contributor Author

jaylevitt commented Sep 24, 2011

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.

@rweng

This comment has been minimized.

Copy link

rweng commented Jan 23, 2012

I just came across the same issue: When loggin in I get the message:

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

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.

@rweng

This comment has been minimized.

Copy link

rweng commented Jan 23, 2012

Also, I noticed that this error appears when the rights are not 755, but 775.

@jaylevitt

This comment has been minimized.

Copy link
Contributor Author

jaylevitt commented Jan 30, 2012

@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"?

@rweng

This comment has been minimized.

Copy link

rweng commented Jan 30, 2012

yes, I do

@jacknagel

This comment has been minimized.

Copy link
Contributor

jacknagel commented Feb 9, 2012

Not sure there's anything that Homebrew can or should do here.

@jaylevitt

This comment has been minimized.

Copy link
Contributor Author

jaylevitt commented Feb 9, 2012

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.

@jacknagel

This comment has been minimized.

Copy link
Contributor

jacknagel commented Feb 9, 2012

I don't think homebrew installs any default .zshrc, which is where you'd do this..

That's correct, closing.

@jacknagel jacknagel closed this Feb 9, 2012

tomhoover added a commit to tomhoover/dotfiles-castle that referenced this issue Jan 11, 2015

"sudo -s" gives "insecure directories and files" error -- Homebrew/le…
…gacy-homebrew#7801:

		added -u flag to compinit to load insecure directories/files

Eriner added a commit to Eriner/prezto that referenced this issue Oct 2, 2015

Remove nonsensical 'security' check
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.

toland added a commit to toland/prezto that referenced this issue Dec 30, 2015

Remove nonsensical 'security' check
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.

@Homebrew Homebrew locked and limited conversation to collaborators Feb 16, 2016

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.