web-dev-qa-db-fra.com

zsh compinit: répertoires non sécurisés

Qu'est-ce que cela signifie et comment puis-je résoudre ce problème?

zsh compinit: insecure directories, run compaudit for list.
Ignore insecure directories and continue [y] or abort compinit [n]?

L'exécution de compaudit renvoie les éléments suivants:

There are insecure directories:
/usr/local/share/zsh/site-functions
zshzsh-completion
170
Alex

Cela a résolu le problème pour moi:

$ cd /usr/local/share/zsh
$ Sudo chmod -R 755 ./site-functions

Crédit: n message sur la liste de diffusion zsh

EDIT: Comme l'a souligné @biocyberman dans les commentaires. Vous devrez peut-être mettre à jour le propriétaire de site-functions ainsi que:

$ Sudo chown -R root:root ./site-functions

Sur ma machine (OSX 10.9), je n’ai pas besoin de le faire mais de YMMV.

EDIT2: Sous OSX 10.11, seul cela fonctionnait:

$ cd /usr/local/share/
$ Sudo chmod -R 755 zsh
$ Sudo chown -R root:staff zsh

De plus, utilisateur: personnel est l’autorisation par défaut correcte sur OSX.

251
chakrit
compaudit | xargs chmod g-w

fera l'affaire, voir http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/

177
Wenbing Li

La plupart des réponses apportent une solution, mais n'indiquez pas pourquoi cet avertissement se produit. Voici un extrait de ZSH compinit :

Pour des raisons de sécurité, compinit vérifie également si le système d'achèvement utiliserait des fichiers n'appartenant pas à root ou à l'utilisateur actuel , ou les fichiers des répertoires accessibles en écriture pour le monde ou par un groupe, ou appartenant à l'utilisateur root ou à l'utilisateur actuel . Si de tels fichiers ou répertoires sont trouvés, compinit demandera si le système de complétion doit vraiment être utilisé. Pour éviter ces tests et utiliser tous les fichiers trouvés sans le demander, utilisez l'option -u et pour que compinit ignore en silence tous les fichiers et répertoires non sécurisés, utilisez l'option -i. Cette vérification de sécurité est entièrement ignorée lorsque l'option -C est donnée.

Par conséquent, la solution implique la résolution de l’un des problèmes suivants:

  • définir l'utilisateur actuel en tant que propriétaire de tous les répertoires/sous-répertoires/fichiers de la cause:

    compaudit | xargs chown -R "$(whoami)"

  • supprimer les autorisations d'écriture pour le groupe/autres pour les fichiers en cause:

    compaudit | xargs chmod go-w

Une autre approche consisterait à ignorer ces vérifications en utilisant

compinit -u

mais je ne le suggère pas vraiment, car cacher des problèmes sous un tapis ne résout que des problèmes à court terme.

43
linkyndy

J'ai les mêmes avertissements quand je Sudo -i démarrer une racine Shell, la solution de @ chakrit ne fonctionnait pas pour moi.

Mais j'ai trouvé -u _ commutateur de compinit fonctionne, par exemple. dans votre .zshrc/zshenv ou où vous avez appelé compinit

compinit -u

NB: Non recommandé pour le système de production

Voir aussi http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization

20
number5

La réponse acceptée ne fonctionnait pas pour moi sur macOs Sierra (10.12.1). Je devais le faire récursif à partir de/usr/local

cd /usr/local
Sudo chown -R <your-username>:<your-group-name> *

Note: Vous pouvez obtenir votre nom d'utilisateur avec whoami et votre groupe avec id -g

7
Franco

Sur macOS Sierra, vous devez exécuter: Sudo chown -R $(whoami):staff /usr/local

4
kkodev

Ces deux lignes ont fixé pour moi.

Sudo chown -R _user_:root /usr/local/share/zsh

Sudo chown -R _user_:root /usr/local/share/zsh/*
3
arglee

sur Mojave, cela a fait l'affaire: Sudo chmod g-w /usr/local/share

1
Sebastien H.

Je l'ai réparé en faisant

Sudo chown root:staff -R /usr/local/share/zsh

dans mon cas, d'autres répertoires dans share/ont aussi un groupe "staff" affecté

0
Franck

Cela fonctionne pour mon Mac après la mise à jour vers High Sierra.

Supprimer l'accès en écriture global:

Sudo chmod g-w /usr/local/share/zsh/site-functions
Sudo chmod g-w /usr/local/share/zsh
0
Hank Chan