zsh-workers
 help / color / mirror / code / Atom feed
From: Andrew Janke <floss@apjanke.net>
To: zsh-workers@zsh.org
Subject: "compinit -i" not excluding some insecure dirs?
Date: Mon, 28 Sep 2015 07:28:22 -0400	[thread overview]
Message-ID: <56092456.3000006@apjanke.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]

Hi, Zsh folks,

What is the expected behavior for compinit's "-i" switch? The doco says 
it will " silently ignore all insecure files and directories". I 
interpret that to mean "silently exclude insecure files and dirs from 
use in the completion system", as opposed to "silently ignore the 
security check failures and use them anyway". If this is the case, it 
looks like there might be an issue with the "compinit -i" code.

When I add an insecure directory to $FPATH, where it's insecure due to 
an openly-writable parent directory but is not itself openly-writable, 
it does not get excluded. For example, if /tmp/insecure is mode 777, but 
/tmp/insecure/zsh.completiond is 755, compaudit will complain about that 
path, but "compinit -i" will still use completions from it.

I'm on OS X 10.9 using zsh 5.0.2 and zsh 5.1.

To reproduce:

spiffy% cd /tmp
spiffy% mkdir -p insecure/zsh.completiond
spiffy% chmod go+w insecure
spiffy% cp /usr/local/share/zsh/functions/_kill 
./insecure/zsh.completiond/_foo
[... and then edit it to say "#compdef foo" at the top ...]
spiffy% ls -ld insecure
drwxrwxrwx  3 janke  wheel  102 Sep 28 07:06 insecure


Then, compinit -i is happy to use it. You can see here that foo is 
picking up the "kill" completion style

spiffy% FPATH="/tmp/insecure/zsh.completiond/:$FPATH"
spiffy% autoload -U compinit
spiffy% autoload -U compaudit
spiffy% compaudit
There are insecure directories:
/tmp/insecure
spiffy% compinit -D -i
spiffy% foo
   787 ttys000    0:00.16 -zsh
  1177 ttys001    0:00.07 -zsh
  1313 ttys002    0:00.39 -/bin/zsh
[ ... snip ...]
spiffy% which _foo
_foo () {
     local curcontext="$curcontext" line state ret=1


If I then make zsh.completiond itself openly-writable, then "compinit 
-i" will no longer use it.

spiffy% chmod go+w /tmp/insecure/zsh.completiond
spiffy% FPATH="/tmp/insecure/zsh.completiond/:$FPATH"
spiffy% autoload -U compinit
spiffy% compinit -D -i
spiffy% which _foo
_foo not found
spiffy% foo
Desktop/      Library/      Public/       local/        var/
Documents/    Movies/       archives/     luggage/


I think this is an issue in compinit. Here's the test it uses for 
excluding insecure directories.

     (( $_i_wdirs[(I)$_i_dir] )) && continue

However, the $_i_wdirs variable only contains the parent dir 
/tmp/insecure, not /tmp/insecure/zsh.completiond itself, so it fails, 
and the dir is used for completion.

spiffy% fpath+=/tmp/insecure/zsh.completiond
spiffy% autoload -U compaudit; compaudit
There are insecure directories:
/tmp/insecure
spiffy% _i_check=1; compaudit; echo $_i_wdirs
/tmp/insecure
spiffy%


Am I understanding this right in terms of what "compinit -i" should be 
doing? Is this a bug?

Cheers,
Andrew



             reply	other threads:[~2015-09-28 11:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-28 11:28 Andrew Janke [this message]
2015-09-28 21:17 ` Bart Schaefer
2015-09-28 21:52   ` Andrew Janke
2015-09-29 17:59     ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56092456.3000006@apjanke.net \
    --to=floss@apjanke.net \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).