compinit trusts .zcompdump even when it's owned by a different user?

compinit trusts .zcompdump even when it's owned by a different user?

[Nick Irvine]

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

This may be a bug or misfeature in zsh, but I don't know it that well and I
may be misunderstanding.

compinit (the function that initializes completions) runs compaudit to
enforce a security model whereby it will only load completion functions
from directories in your $fpath that are considered "secure" (owned by root
or me, not world-writable, etc.). It will warn the user about insecure
paths and prompt to either skip them or abort. That's all well and good.

It creates a cache of the results at ~/.zcompdump. AFAICT, it is only
invalidated (i.e., deleted)*manually*.

I'm not entirely clear what's in the cache, so I can't say if this is
really a big security issue. But, at the very least, compinit will consider
the cache valid even if it's owned by a different user, thereby avoiding
loading completion functions that *are* valid for the current user but
*weren't* for the previous one.

This is happening to me every time I use sudo -s where my zsh installation
is owned by me (OS X homebrew). It writes an incomplete completion cache.
Then next shell I start, it loads the busted cache and doesn't see any
completions.

Is this my problem? ZSH's? Homebrew's?

(This is a cross-post from Stack Overflow.)

Re: compinit trusts .zcompdump even when it's owned by a different user?

[Peter Stephenson]

On Wed, 06 Jan 2016 01:58:55 +0000
Nick Irvine <nfirvine@nfirvine.com> wrote:
> This may be a bug or misfeature in zsh, but I don't know it that well and I
> may be misunderstanding.
> 
> compinit (the function that initializes completions) runs compaudit to
> enforce a security model whereby it will only load completion functions
> from directories in your $fpath that are considered "secure" (owned by root
> or me, not world-writable, etc.). It will warn the user about insecure
> paths and prompt to either skip them or abort. That's all well and good.
> 
> It creates a cache of the results at ~/.zcompdump. AFAICT, it is only
> invalidated (i.e., deleted)*manually*.

It's updated automatically, but never invalidated automatically.

> I'm not entirely clear what's in the cache, so I can't say if this is
> really a big security issue. But, at the very least, compinit will consider
> the cache valid even if it's owned by a different user, thereby avoiding
> loading completion functions that *are* valid for the current user but
> *weren't* for the previous one.

The standard fix for this is to point different users at different
files.  Run compinit with the -d option, e.g.

compinit -d ~/.compdump_${USER}

This is the only way you're going to have two users in the same area
with the same basic environment (home directory in particular)
co-existing (regardless of compaudit).

The security issue is a separate one and I don't have a glib answer to
that.  I think the assumption has been the dump file, unlike the
contents of your $fpath, will always be written in an area to which no
one other than you and the superuser has access, unless you've
explicitly given it to someone.  Certainly, as currently implemented,
compaudit is really there to check for zsh functions you don't want to
autoload owing to the fact that $fpath might point at anything --- not as
a security check for files in your own area, which is a whole different
ball game.  If you're worried about the dump file, why are .zshrc or
.zshenv, typically in the same area, not even more of a worry?

pws

Re: compinit trusts .zcompdump even when it's owned by a different user?

[Nick Irvine]

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

>
> The standard fix for this is to point different users at different
> files.  Run compinit with the -d option, e.g.
>
> compinit -d ~/.compdump_${USER}
>
> This is the only way you're going to have two users in the same area
> with the same basic environment (home directory in particular)
> co-existing (regardless of compaudit).
>

I'm inclined to agree. I'm using prezto and they do compinit for you. Am
trying to convince maintainer that a -d is a good idea.

The security issue is a separate one and I don't have a glib answer to
> that.  I think the assumption has been the dump file, unlike the
> contents of your $fpath, will always be written in an area to which no
> one other than you and the superuser has access, unless you've
> explicitly given it to someone.  Certainly, as currently implemented,
> compaudit is really there to check for zsh functions you don't want to
> autoload owing to the fact that $fpath might point at anything --- not as
> a security check for files in your own area, which is a whole different
> ball game.  If you're worried about the dump file, why are .zshrc or
> .zshenv, typically in the same area, not even more of a worry?
>

Yep, good points. It's more a matter of my expectations: I didn't expect
zsh to trust a cache owner by another, so it added to my confusion.

Anyway...

After some more debugging, I found out that awscli's zsh completion script
(which I was sourcing) was causing compinit to be run again, causing havoc.
So I've fixed my problem (in that I can't repro it now). Not sure if
there's still anything to be done here or not.