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

[Nick Irvine <nfirvine@nfirvine.com>]

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