zsh compinit: niezabezpieczone katalogi

Co to znaczy i jak mogę to naprawić?

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

Uruchomienie compauditzwraca:

There are insecure directories:
/usr/local/share/zsh/site-functions

Naprawiłem to dla mnie:

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

Kredyt: post na liście mailingowej zsh

EDYCJA: Jak wskazał @biocyberman w komentarzach. Może być konieczne zaktualizowanie właściciela site-functions:

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

Na moim komputerze (OSX 10.9) nie muszę tego robić, ale YMMV.

EDYCJA 2: W OSX 10.11 działało tylko:

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

Również użytkownik: personel jest prawidłowym domyślnym pozwoleniem na OSX.

compaudit | xargs chmod g-w

załatwi sprawę, patrz http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/

Większość odpowiedzi zawiera rozwiązanie, ale nie wspominaj, dlaczego pojawia się to ostrzeżenie. Oto fragment z zsh za compinit :

Ze względów bezpieczeństwa compinit sprawdza również, czy system uzupełniania użyłby plików, które nie są własnością użytkownika root lub bieżącego użytkownika , lub plików w katalogach, które można zapisać na całym świecie lub w grupie lub które nie są własnością użytkownika root lub bieżącego użytkownika . Jeśli takie pliki lub katalogi zostaną znalezione, compinit zapyta, czy naprawdę należy użyć systemu uzupełniania. Aby uniknąć tych testów i sprawić, że wszystkie znalezione pliki będą używane bez pytania, użyj opcji -u, a aby compinit po cichu zignorował wszystkie niebezpieczne pliki i katalogi, użyj opcji -i. Ta kontrola bezpieczeństwa jest całkowicie pomijana, gdy podano opcję -C.

W związku z tym rozwiązanie zakłada naprawienie jednego (lub wszystkich) następujących elementów:

• ustawienie bieżącego użytkownika jako właściciela wszystkich katalogów / podkatalogów / plików w przyczynie:

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

• usunięcie uprawnień do zapisu dla grupy / innych plików dla przyczyny:

  compaudit | xargs chmod go-w
  

Innym podejściem byłoby pominięcie tych kontroli za pomocą

compinit -u

ale tak naprawdę nie sugeruję tego, ponieważ ukrywanie problemów pod dywanikiem rozwiązuje problemy tylko w krótkim okresie.

Otrzymałem takie same ostrzeżenia, kiedy sudo -iuruchamiam powłokę roota, rozwiązanie @ chakrit nie działało dla mnie.

Ale znalazłem -uprzełącznik compinitprac, np. W twoim .zshrc / zshenv lub gdzie dzwoniłeścompinit

compinit -u

NB: Nie zalecane dla systemu produkcyjnego

Zobacz także http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization

Działa to na moim komputerze Mac po aktualizacji do High Sierra.

Usuń dostęp do zapisu grupowego:

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

Najlepiej jest ograniczyć zmianę do katalogów zsh.

Przyjęta odpowiedź nie działała dla mnie w systemie macOs Sierra (10.12.1). Musiałem to zrobić rekurencyjnie z / usr / local

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

Uwaga: możesz uzyskać swoją nazwę użytkownika whoamii swoją grupę za pomocąid -g

Te dwie linie zostały dla mnie naprawione.

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

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

W systemie macOS Sierra musisz uruchomić: sudo chown -R $(whoami):staff /usr/local

Naprawiłem to, robiąc

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

w moim przypadku inne katalogi wewnątrz udostępniają / mają również przypisaną grupę „pracowników”

na mojejve udało się to: sudo chmod go-w /usr/local/share

Moją sugestią byłoby uruchomienie compaudit, a następnie po prostu naprawienie uprawnień do katalogów znalezionych podczas audytu. Upewnij się, że zidentyfikowane katalogi nie mają uprawnień do zapisu dla grupy lub innych.

To była jedyna rzecz, która działała dla mnie z https://github.com/zsh-users/zsh-completions/issues/433#issuecomment-600582607 . Dzięki https://github.com/malaquiasdev !

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

Moja maszyna:

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

Oto co zrobiłem

1. uruchom, compaudita wyświetli się lista katalogów, które jej zdaniem są niezabezpieczone.

2. uruchom sudo chmod -R 755 target_directory (przykład sudo chmod -R 755 /usr/local/share/zsh:)

Przykład:

compaudit

zwroty:

/ usr / local / share / zsh

więc biegnę

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

czytaj więcej tutaj link

Dziś rano niektóre pakiety w moim systemie zostały zaktualizowane i zostawił mi ten komunikat o błędzie. Używam Ubuntu 18.04.

Wygląda na to, że coś w aktualizacji zmieniło nazwę użytkownika i grupę na liczby, zamiast root:

# 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

Po prostu zmieniłem użytkownika i grupę dla tego pliku z powrotem rooti problem zniknął. I nie , nie trzeba zmieniać żadnych uprawnień, i ostrzegają przed tak robi, chyba że przyczyna problemu jest zrozumiałe.

sudo chown root _code && sudo chgrp root _code

Po przełączeniu 131i 142ponownym rooturuchomieniu ten komunikat o błędzie z zsh zniknął.

1. uruchom, compaudita wyświetli się lista katalogów, które według niej są niepewne

2. sudo chown -R username:root target_directory

3. sudo chmod -R 755 target_directory

Ostatnio miałem takie samo ostrzeżenie w sprawie Cataliny. Łatwym obejściem tego problemu jest umieszczenie go na górze pliku .zshrc

ZSH_DISABLE_COMPFIX=true

Żadne z wymienionych rozwiązań nie działało dla mnie. Zamiast tego skończyłem odinstalowywanie i ponowne instalowanie Homebrew, co załatwiło sprawę. Instrukcje odinstalowania można znaleźć tutaj: http://osxdaily.com/2018/08/12/how-uninstall-homebrew-mac/

uruchomienie tego polecenia działało dla mnie na moim mac OS Catalina:

compaudit | xargs chmod g-w,o-w

Rozwiązanie MAC OS X:

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

Również „użytkownik: personel = domyślny użytkownik root w OSX.

Ten problem wystąpił po uruchomieniu google-cloud-sdk wystąpił skryptu instalacyjnego, który dodaje polecenie uzupełniające do powłoki za pomocą wpisu w .zshrc.

Następujące instrukcje homebrew dla konfigurowania uzupełnień w zsh był pomocny.