From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18722 invoked by alias); 6 Jan 2016 09:37:07 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 21120 Received: (qmail 26801 invoked from network); 6 Jan 2016 09:37:05 -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 autolearn=ham autolearn_force=no version=3.4.0 X-AuditID: cbfec7f5-f79b16d000005389-a0-568ce03d1994 Date: Wed, 06 Jan 2016 09:36:59 +0000 From: Peter Stephenson To: Nick Irvine , zsh-users@zsh.org Subject: Re: compinit trusts .zcompdump even when it's owned by a different user? Message-id: <20160106093659.2cd1ad5d@pwslap01u.europe.root.pri> In-reply-to: References: Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsVy+t/xa7q2D3rCDJZNErU4v3cJs8WOkysZ HZg8TkyZzuyx6uAHpgCmKC6blNSczLLUIn27BK6MKRdbmQsuC1RsecbawLiOt4uRk0NCwERi 4osj7BC2mMSFe+vZuhi5OIQEljJKnL3ygxXCaWCSOHHiCQuEc5pR4uu9ZijnDKPE6vm9YP0s AqoSUw+vYgSx2QQMJaZumg1miwhYSbyZ/Y8FxBYWCJaYt7QPzOYVsJdYs/IMG4jNCRS/s+w2 WFxIIEBi29+FTCA2v4C+xNW/n5gg7rOXmHnlDCNEr6DEj8n3wOqZBbQkNm9rYoWw5SU2r3nL DDFHXeLG3d3sExiFZyFpmYWkZRaSlgWMzKsYRVNLkwuKk9JzjfSKE3OLS/PS9ZLzczcxQkL8 6w7GpcesDjEKcDAq8fAKyPSECbEmlhVX5h5ilOBgVhLhDSkGCvGmJFZWpRblxxeV5qQWH2KU 5mBREueduet9iJBAemJJanZqakFqEUyWiYNTqoExKP5Kg5GAusdDO2Hjtfe807N8audMSmTP VapYv+wub/xU8Vlibf6WKnOqvso7r5/3asePqa/zAmzFPj3+qGVql2fXzq6dt9M89+ZVnsbS 9Gnx5y/vvNqhsv/cEpsZrOy6NTKtx7YLfFb9OPfud56prAu3mK14yvNqyvtgbo5NH8rXWqVl 3rNRYinOSDTUYi4qTgQA4pbPJW0CAAA= On Wed, 06 Jan 2016 01:58:55 +0000 Nick Irvine 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