Re: compinit insecure warning with trusted user

[Stephen Romansky <sk.romansky@xxxxxxxxx>]

The -u did the trick.

The fpath and the binary are both owned by a user in the admin group. I
talked to two people running os x and one lets their main account be an
admin so the error does not appear, and the other individual uses the -u
flag. I would guess that most people on os x and running zsh use these two
solutions.

The package manager installs content to /usr/local which is owned by the
admin grouped account.

On Mon, Jun 8, 2015 at 1:48 AM, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
wrote:

> On Jun 7,  1:09pm, Stephen Romansky wrote:
> }
> } Zsh in owned by an admin account that isn't named root, and is not the
> } current user.
> }
> } Now,
> }
> http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Use-of-compinit
> } states that the *compaudit* will throw the warning if the completion
> system
> } is not owned by root or the current user. Which is the case I have.
>
> That paragraph is missing one detail, which is that compaudit also tries
> to identify the user that owns the zsh binary itself, and allows fpath
> directories to be owned by that user as well as root or the current user.
>
> Do you in fact have a case where the files in fpath are not owned by the
> same user as the zsh binary?  If the binary and the function library ARE
> owned by the same user, perhaps there is an ownership test you can help
> us improve.  Currently it examines
>     /proc/$$/exe
>     /proc/$$/object/a.out
>
> There's also some special code for debian.  If your situation is common on
> some particular distribution, perhaps we need to special-case that, too.
>
> } So, can the admin and/or wheel group be added to this set of
> } exceptions? Or, is it simpler to just add the ignore flag to
> } *compinit* on the system in question?
>
> You probably want "compinit -u" (the "use the library anyway" flag) rather
> than the ignore flag.
>