"compinit -i" not excluding some insecure dirs?

"compinit -i" not excluding some insecure dirs?

[Andrew Janke]

[-- 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

Re: "compinit -i" not excluding some insecure dirs?

[Bart Schaefer]

On Sep 28,  7:28am, Andrew Janke wrote:
}
} 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.

There's only so much that compinit can do.  It doesn't actually change
your $fpath to remove the insecure directories; it merely doesn't look
at them when scanning for files that contain #compdef, #autoload, etc.
on the first line.

So if you have fpath=(/insecure /secure) and there is _kill in both
places, the one in /secure will be used for #compdef at time of
compinit, but the one in /insecure will still be used at the time
the function is called, because $fpath search order says it should.

I must grudgingly admit that this is closely related to Ray Andrew's
(incorrect) expectation that once the "autoload" *command* is issued,
the source file of the corresponding function is locked down.

To really be secure, a re-check would have to be done at the instant
of the first function call, or all the functions would have to be pre-
loaded at the instant of compaudit (which is exactly what compinit is
attempting to *avoid* doing).

Re: "compinit -i" not excluding some insecure dirs?

[Andrew Janke]

On 9/28/15 5:17 PM, Bart Schaefer wrote:
> On Sep 28,  7:28am, Andrew Janke wrote:
> }
> } 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.
>
> There's only so much that compinit can do.  It doesn't actually change
> your $fpath to remove the insecure directories; it merely doesn't look
> at them when scanning for files that contain #compdef, #autoload, etc.
> on the first line.
>
> So if you have fpath=(/insecure /secure) and there is _kill in both
> places, the one in /secure will be used for #compdef at time of
> compinit, but the one in /insecure will still be used at the time
> the function is called, because $fpath search order says it should.
But in this case I think it *is* scanning the insecure directory: I had 
a _foo only in /insecure, not in /secure, and it still got picked up by 
compinit and used for completion. (Sorry if my example was unclear: I 
copied _kill to _foo just so I'd have a readily recognizable completion 
output.)

But that's a good point about $fpath at the function call time really 
being what matters.
>
> I must grudgingly admit that this is closely related to Ray Andrew's
> (incorrect) expectation that once the "autoload" *command* is issued,
> the source file of the corresponding function is locked down.
>
> To really be secure, a re-check would have to be done at the instant
> of the first function call, or all the functions would have to be pre-
> loaded at the instant of compaudit (which is exactly what compinit is
> attempting to *avoid* doing).

Re: "compinit -i" not excluding some insecure dirs?

[Bart Schaefer]

On Sep 28,  5:52pm, Andrew Janke wrote:
}
} But in this case I think it *is* scanning the insecure directory: I had 
} a _foo only in /insecure, not in /secure, and it still got picked up by 
} compinit and used for completion.

Hmm.

compaudit returns true when no insecure directories are found or when
it is passed the -u option.

compinit sets _comp_secure only when compaudit returns true.

compdump writes the files from the fpath directories into the dumpfile
only when _comp_secure is set.  However, I'm not sure this accomplishes
what was intended.

And in any case compinit doesn't otherwise change its behavior when
passed -i, so yes, that's clearly a bug in the case where the dump
file does not already exist.