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

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.


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/


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.


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


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.


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


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/*

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


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"


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


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.



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


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.


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


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


1

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

compaudit | xargs chmod g-w,o-w


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.


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.