From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2007 invoked by alias); 28 Sep 2015 11:28:26 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 36673 Received: (qmail 4892 invoked from network); 28 Sep 2015 11:28:24 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.0 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Rr FPOsk0pVXw9YZqATxpo9qV8yU=; b=dDH0zA7jJPBvD9A6lNErNzFD8XUFLo0k+f TcYGf9uCUx45mnkVYal9vy3sJv7ZiUJ5BGKnzzi+vbG9HdfxnY0OglnKtiOHfmo9 /vpm/808vjmd5Y1S36dvdbEn6mxxCfBcvrHF9+sNsHYMCgf03ZJ9Cc4K5l/+pqk8 6IGyrmNnI= X-Sasl-enc: UgnwQKlbdLYOAcFUf3El1pbFyRAHXbPRngPxqjBrpnhc 1443439702 To: zsh-workers@zsh.org From: Andrew Janke Subject: "compinit -i" not excluding some insecure dirs? Message-ID: <56092456.3000006@apjanke.net> Date: Mon, 28 Sep 2015 07:28:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040704050103030607000804" --------------040704050103030607000804 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 --------------040704050103030607000804--