zsh compinit: directory non sicure

238

Cosa significa e come posso ripararlo?

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

L'esecuzione dei compauditritorni è la seguente:

There are insecure directories:
/usr/local/share/zsh/site-functions
zsh  zsh-completion 
— alex
fonte
2
Qualcuno sa perché si verifica questo avviso?
— Blaszard,
3
Un anno dopo che @Blaszard ha posto la domanda valida (come commento), "linkyndy" ha risposto di seguito (come risposta).
— Happy Green Kid Naps,

Risposte:

342

Questo mi ha risolto:

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

Credito: un post sulla mailing list di zsh

EDIT: Come sottolineato da @biocyberman nei commenti. Potrebbe essere necessario aggiornare anche il proprietario di site-functions:

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

Sulla mia macchina (OSX 10.9), non ho bisogno di farlo ma YMMV.

EDIT2: su OSX 10.11, solo questo ha funzionato:

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

Anche utente: staff è l'autorizzazione predefinita corretta su OSX.

— chakrit
fonte
1
cosa succede se non hai root
— kirill_igum
2
@kirill_igum per "nessuna radice" intendevi "nessun accesso alla radice "? In tal caso, dovresti copiare i file in una cartella a cui hai accesso, correggere .zshenve .zshrcutilizzare la nuova cartella e fare lo stesso chmodsulla nuova cartella che ho pubblicato con la cartella.
— Chakrit,
@kirill_igum vedi il messaggio della mailing list a cui ho collegato.
— Chakrit,
1
Ho notato che dopo aver impostato il proprietario su root, l'accesso in scrittura doveva essere revocato sia per il gruppo che per l'altro. Ho modificato il chmodcomando in sudo chmod -R go-w zsh.
— gdvd,
1
Nota: ho dovuto collegamenti simbolici in /usr/local/share/zsh/site-functionsa /usr/local/Cellare ha dovuto chown -R root:staff /usr/local/Cellaranche prima di questo ha funzionato.
— mVChr
268 
compaudit | xargs chmod g-w

farà il trucco, vedi http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/

— Wenbing Li
fonte
6
Questo è! Rimozione dell'autorizzazione di scrittura al gruppo. Grazie
— glarrain,
8
Risposta molto migliore, va notato che compauditpuò essere utilizzato per diagnosticare problemi come questi e risolverli.
— Wolph,
8
Nota che potresti anche dover cambiare il proprietario dei file in root - Ho dovuto:compaudit | xargs chown root
— Brad Parks
4
Questa è sicuramente la soluzione migliore per me. Ho installato i completamenti zsh e zsh con Homebrew, quindi ovviamente non volevo cambiarlo per farne parte di root.
— Katy Lavallee,
2
compaudit | xargs chmod g-winsieme ha ompaudit | xargs chown rootfunzionato anche per me e sembrava che HomeBrew fosse felice. qualcuno può spiegare cosa sta succedendo un po 'di più.
— Nyxee,
76

La maggior parte delle risposte viene fornita con una soluzione, ma non menzionare il motivo per cui si verifica questo avviso. Ecco un estratto dal compinit di ZSH :

Per motivi di sicurezza compinit verifica anche se il sistema di completamento utilizzerà file non di proprietà di root o dell'utente corrente o file in directory scrivibili in tutto il mondo o di gruppo o che non sono di proprietà di root o dell'utente corrente . Se vengono trovati tali file o directory, compinit chiederà se il sistema di completamento dovrebbe davvero essere usato. Per evitare questi test e fare in modo che tutti i file trovati vengano utilizzati senza chiedere, utilizzare l'opzione -u e fare in modo che compinit ignori silenziosamente tutti i file e le directory non sicuri utilizzare l'opzione -i. Questo controllo di sicurezza viene ignorato completamente quando viene fornita l'opzione -C.

Quindi, la soluzione implica il fissaggio di uno (o tutti) dei seguenti:

  • l'impostazione dell'utente corrente come proprietario di tutte le directory / sottodirectory / file nella causa:

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

  • rimozione delle autorizzazioni di scrittura per il gruppo / altri per i file nella causa:

    compaudit | xargs chmod go-w

Un altro approccio sarebbe quello di saltare questi controlli usando

compinit -u

ma non lo suggerisco davvero, poiché nascondere i problemi sotto un tappeto risolve problemi a breve termine.

— linkyndy
fonte
1
Grazie. Sono sorpreso che le persone digitino casualmente i comandi senza capire realmente il problema.
— grido
3
Che dire di un sistema multiutente? In tale scenario, chown -R "$(whoami)"per i file all'esterno della home directory come /usr/local/non funzionerebbe. Secondo i documenti, non avrebbe più senso rendere i file di proprietà root?
— goetzc,
Mi piace questa risposta al meglio. Mi ha fatto pensare al perché mi è successo. Si scopre che è successo dopo aver aggiunto un altro utente al gruppo principale del mio utente. Le directory in $ HOME / .antigen / bundles erano di proprietà del mio utente e del mio gruppo. Quindi nel mio caso la rimozione di quell'utente dal gruppo ha risolto il problema.
— Samuel,
25

Ho ricevuto gli stessi avvisi quando ho sudo -iavviato una shell di root, la soluzione di @ chakrit non ha funzionato per me.

Ma ho trovato il -ucambio di compinitopere, ad esempio nel tuo .zshrc / zshenv o dove hai chiamatocompinit

compinit -u

NB: non raccomandato per il sistema di produzione

Vedi anche http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization

— number5
fonte
quella era l'unica soluzione che ha funzionato per me. stavo cercando di usare zsh con compinit sul sottosistema Linux su Windows 10
— gennaio
17

Questo funziona per il mio Mac dopo l'aggiornamento a High Sierra.

Rimuovere l'accesso in scrittura al gruppo:

sudo chmod g-w /usr/local/share/zsh/site-functions
sudo chmod g-w /usr/local/share/zsh

È meglio limitare la modifica alle directory zsh.

— Hank Chan
fonte
1
sudo chmod gw / usr / local / share / zsh / site-funzioni (ha funzionato per me in mac 10.15)
— shijin
2
Questa è stata l'unica correzione che ha funzionato per me su Mac Catalina
— user8467470 il
1
Questa correzione ha funzionato anche per me su MacOS Catalina. Grazie!
— Tyler
12

La risposta accettata non ha funzionato per me su macOs Sierra (10.12.1). Ho dovuto farlo in modo ricorsivo da / usr / local

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

Nota: è possibile ottenere il nome utente con whoamie il gruppo conid -g

— Franco
fonte
4
Ho dovuto farlo anche su Sierra, anche se su un sistema multiutente l'utente / gruppo corretto dovrebbe essere root: staff
— Marshall Eubanks
5

Queste due linee hanno risolto per me.

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

sudo chown -R _user_:root /usr/local/share/zsh/*
— arglee
fonte
3
Lavora per me! Uso un account di rete sul mio PC - Ubutun 16.04 sudo chown -R $(whoami):root /usr/local/share/zsh sudo chown -R $(whoami):root /usr/local/share/zsh/*
— hoangdv il
5

Su macOS Sierra devi eseguire: sudo chown -R $(whoami):staff /usr/local

— kkodev
fonte
4

L'ho risolto facendo

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

nel mio caso altre directory all'interno condividono / hanno anche assegnato il gruppo "staff"

— Franck
fonte
La domanda non è in argomento per StackTranslate.it, come definito nel Centro assistenza . Per favore, non rispondere a tali domande; invece, dovresti segnalarli per attirare l'attenzione e verranno chiusi o migrati in modo appropriato.
— Toby Speight,
4

su Mojave, questo ha funzionato: sudo chmod go-w /usr/local/share

— Sebastien H.
fonte
1
Meglio ancora:sudo chmod -R go-w /usr/local/share
— ecmanaut
3

Il mio suggerimento sarebbe di eseguire compaudit e quindi semplicemente correggere le autorizzazioni sulle directory trovate dall'audit. Assicurarsi che le directory identificate non dispongano delle autorizzazioni di scrittura per gruppo o altro.

— Tiamot
fonte
3

La mia macchina:

System Version: macOS 10.15.4 (19E287)
Kernel Version: Darwin 19.4.0

Quindi ecco cosa ho fatto

  1. esegui compaudite ti fornirà un elenco di directory che ritiene non sicure.

  2. corri sudo chmod -R 755 target_directory (esempio sudo chmod -R 755 /usr/local/share/zsh:)

Exmaple:

compaudit

ritorna:

/ Usr / local / share / zsh

quindi corro

sudo chmod -R 755 /usr/local/share/zsh

leggi di più qui link

— Sultanmyrza Kasymbekov
fonte
2

Questa mattina, alcuni pacchetti nel mio sistema sono stati aggiornati e mi hanno lasciato questo messaggio di errore. Sto usando Ubuntu 18.04.

Apparentemente, qualcosa nell'aggiornamento ha cambiato il nome utente e il gruppo in numeri, anziché rootin questo modo:

# There are insecure files: /usr/share/zsh/vendor-completions/_code
# sudo ls -alh
-rw-r--r-- 1  131  142 2.6K 2019-10-10 16:28 _code

Ho semplicemente cambiato l'utente e il gruppo per questo file roote il problema è scomparso. Ho non bisogno di cambiare tutte le autorizzazioni, e mettere in guardia contro questo modo a meno che non si comprende la causa del problema.

sudo chown root _code && sudo chgrp root _code

Dopo il passaggio 131e il 142ritorno a root, questo messaggio di errore da zsh è andato via.

— Todd
fonte
2

  1. esegui compaudite ti fornirà un elenco di directory che ritiene non sicure

  2. sudo chown -R username:root target_directory

  3. sudo chmod -R 755 target_directory

— Sharif Mohammad Eunus
fonte
2

Di recente ho ricevuto lo stesso avvertimento su Catalina. Una soluzione semplice è quella di mettere questo in cima al tuo .zshrc

ZSH_DISABLE_COMPFIX=true
— Frédérick
fonte
1

l'esecuzione di questo comando ha funzionato per me sul mio mac OS Catalina:

compaudit | xargs chmod g-w,o-w

— Miguel Julio
fonte
1

Soluzione MAC OS X:

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

Inoltre "user: staff = utente root predefinito su OSX.

— jpmottin
fonte
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.