From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8539 invoked by alias); 6 Jan 2016 23:41:53 -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: 21122 Received: (qmail 14383 invoked from network); 6 Jan 2016 23:41:51 -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-sha256; c=relaxed/relaxed; d=nfirvine-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=0AZNISDtUTOkXD9JIYnibURQxkeQkFaH8uX1LFez8hQ=; b=SdeUntyDWwWv1KyLn28Uxs2JXmpvZFnT4k+ZjMat1hpkacqiEwNFwhK4oTMjrIRZxq cfVQ7fNgsYv0AR1dm3LtbbRLD/C3EWsLnqNGRsWRITkAleok4XCtc41Y17V+ZrKpcAx+ R4UtNXV/Gj4NEV1IwCKTH905l88euYukkzE1TdPCDwVm0ZOFaLIm6OrzZHRzAwoPmsVj 7ZFiB/Bv9GGxjsdpr7dvOk20ADADoNMu58JhpUQGtSWVY8ffOlwP+1yUehgDZtVIPxlp 5QTRzJLQn4SNTEl+TKrzAQxvzmzyFIa8VfUkEor6VFmz++oooSZYLSgGfhj8zjnFdFpL /lFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=0AZNISDtUTOkXD9JIYnibURQxkeQkFaH8uX1LFez8hQ=; b=igRMM9PoJpn4t/tMuSooQ5nTb1ZkNJVZVNxcOxTyzuoyTpyhrgsjXxppzxEQt6w01O 1KeSXWVeTAofwOHE4QDlIU36Ch+pP5ZDce2I6CCI59xhlh4NMmbtGP6X8/1lTOOdPk0s ndTPBriy9pbUJDZ89MU4yNaMs5K73Im08+Gyq+mqyEkL/n5XcC/xcCOFi4794iO1zo8T WZAjhQXpHLRSFulorc8gjBVXVY6OyksXBjb4rXxeDNlXInpBa9YldFpDCvZNEU3DcoFO 5wWRE0vfjmxmsMrv7sAYMG5v1sCFuW8jH+0mVDYf+az+6TZIkujAdh1MikEcBCa3iU2r FJiA== X-Gm-Message-State: ALoCoQnJwH3nEMRrvObCv4z4b+NO+P6YDDjAjNRfUNzOnSbZVXUaAApk6h2nQWs2cv+PRStfkd7ztMpyepTTMpRfX/VEJAGt5w== X-Received: by 10.50.143.105 with SMTP id sd9mr1297194igb.51.1452123708954; Wed, 06 Jan 2016 15:41:48 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20160106093659.2cd1ad5d@pwslap01u.europe.root.pri> References: <20160106093659.2cd1ad5d@pwslap01u.europe.root.pri> From: Nick Irvine Date: Wed, 6 Jan 2016 15:41:29 -0800 Message-ID: Subject: Re: compinit trusts .zcompdump even when it's owned by a different user? To: Peter Stephenson , zsh-users@zsh.org Content-Type: multipart/alternative; boundary=001a1134ca3ad7b4c20528b2e5cd --001a1134ca3ad7b4c20528b2e5cd Content-Type: text/plain; charset=UTF-8 > > 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. --001a1134ca3ad7b4c20528b2e5cd--