benw2/wezm.net
1
0
Fork 0
forked from wezm/wezm.net
Code Pull requests Activity

QA /technical/2008/09/zsh-cygwin-and-insecure-directories/

Browse source
This commit is contained in:
Wesley Moore 2010-03-22 07:50:51 +11:00
parent 0e0fc9552e
commit c5e2c2e9f8
2 changed files with 32 additions and 31 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

47
content/technical/2008/09/zsh-cygwin-and-insecure-directories.html
View file

@ -1,44 +1,45 @@
In order to cope with having to use Windows at work I run Cygwin. My shell of choice is zsh. For whatever reason the Cygwin package of zsh installs with a serious of directories that the zsh completion system deems to be insecure and it makes sure you know this. Each time a new shell is opened (in my case through a Windows native rxvt terminal) I would receive the following warning: In order to cope with having to use Windows at work I run Cygwin. My shell of choice is zsh. For whatever reason the Cygwin package of zsh installs with a series of directories that the zsh completion system deems to be insecure and it makes sure you know this. Each time a new shell is opened (in my case through a Windows native rxvt terminal) I would receive the following warning:
<code>Ignore insecure directories and continue [ny]?</code> Ignore insecure directories and continue [ny]?
Pressing 'y' becomes a bit tedious after a while so I decided to track down these insecure directories and fix them. Pressing 'y' becomes a bit tedious after a while so I decided to track down these insecure directories and fix them.
<!--more--> <!--more-->
<tt>man zshcompsys</tt> reveals the following about the security check: <tt>man zshcompsys</tt> reveals the following about the security check:
<blockquote>For security reasons compinit also checks if the completion system > 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 > 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 > 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, > 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 > 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 > 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 > the option -u, and to make compinit silently ignore all insecure files
and directories use the option -i. This security check is skipped > and directories use the option -i. This security check is skipped
entirely when the -C option is given. > entirely when the -C option is given.
>
The security check can be retried at any time by running the function > The security check can be retried at any time by running the function
compaudit. > compaudit.
</blockquote>
Running compaudit revealed the following: Running compaudit revealed the following:
<code>% compaudit
% compaudit
There are insecure directories: There are insecure directories:
/usr/share/zsh/site-functions /usr/share/zsh/site-functions
/usr/share/zsh/4.3.4/functions /usr/share/zsh/4.3.4/functions
/usr/share/zsh /usr/share/zsh
/usr/share/zsh/4.3.4</code> /usr/share/zsh/4.3.4
Examining the permissions on these directories showed they were all group writable. Examining the permissions on these directories showed they were all group writable.
<code>% ls -ld /usr/share/zsh/site-functions % ls -ld /usr/share/zsh/site-functions
drwxrwx---+ 2 wmoore mkgroup-l-d 0 Sep 4 10:54 /usr/share/zsh/site-functions</code> drwxrwx---+ 2 wmoore mkgroup-l-d 0 Sep 4 10:54 /usr/share/zsh/site-functions
Stripping them of the group write permission fixed the problem and made starting a new shell a little more pleasant. Stripping them of the group write permission fixed the problem and made starting a new shell a little more pleasant.
<code>% chmod g-w /usr/share/zsh/site-functions /usr/share/zsh/4.3.4/functions /usr/share/zsh /usr/share/zsh/4.3.4 % chmod g-w /usr/share/zsh/site-functions /usr/share/zsh/4.3.4/functions /usr/share/zsh /usr/share/zsh/4.3.4
% compaudit % compaudit
% %
</code>
<strong>Update:</strong> kylexlau provides this one line solution for correcting to permissions on each of the directories that compaudit returns: **Update:** _kylexlau_ provides this one line solution for correcting to permissions on each of the directories that compaudit returns:
<code>compaudit | xargs chmod g-w</code>
compaudit | xargs chmod g-w

4
output/css/screen.css
View file

@ -95,8 +95,8 @@ sup {
font-size: 0.8em; font-size: 0.8em;
} }
pre,code { pre,code,tt {
font-size: 12px; font-size: 13px;
font-family: Consolas, "Andale Mono", "Liberation Mono", Menlo, Monaco, "Bitstream Vera Sans Mono", fixed; font-family: Consolas, "Andale Mono", "Liberation Mono", Menlo, Monaco, "Bitstream Vera Sans Mono", fixed;
} }