zsh compinit: небезопасные каталоги

238

Что это значит и как я могу это исправить?

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

Запуск compauditвозвращает следующее:

There are insecure directories:
/usr/local/share/zsh/site-functions
Alex
источник
2
Кто-нибудь знает, почему возникает это предупреждение?
Blaszard
3
Через год после того, как @Blaszard задал правильный вопрос (в качестве комментария), «linkyndy» ответил на него ниже (в качестве ответа).
Happy Green Kid Naps

Ответы:

343

Это исправило это для меня:

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

Кредит: сообщение в списке рассылки Zsh


РЕДАКТИРОВАТЬ: Как указано @biocyberman в комментариях. Вам также может понадобиться обновить владельца site-functions:

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

На моей машине (OSX 10.9) мне не нужно это делать, кроме YMMV.

EDIT2: на OSX 10.11, только это работало:

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

Также user: staff - правильное разрешение по умолчанию для OSX.

chakrit
источник
1
Что делать, если у вас нет рута
kirill_igum
2
@kirill_igum на «нет корня» не вы имели в виду «нет корневого доступа »? Если это так, то вы должны скопировать файлы в папку, к которой у вас есть доступ, исправить .zshenvи .zshrcиспользовать новую папку и сделать то же самое chmodв новой папке, как я опубликовал в этой папке.
Чакрит
@kirill_igum см. сообщение в списке рассылки, с которым я связан.
чакрит
1
Я заметил, что после установки владельца на root права на запись должны были быть аннулированы как для группы, так и для других. Я изменил chmodкоманду на sudo chmod -R go-w zsh.
gdvd
1
Примечание: у меня были символические ссылки /usr/local/share/zsh/site-functionsна /usr/local/Cellarи я должен был chown -R root:staff /usr/local/Cellarтакже, прежде чем это сработало.
mVChr
271
compaudit | xargs chmod g-w

сделаем трюк, см. http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/

Венбинг Ли
источник
6
Это оно! Удаление разрешения на запись в группу. Спасибо
гларрейн
8
Гораздо лучший ответ, следует отметить, что compauditможет использоваться для диагностики подобных проблем, а также для их устранения.
Вольф
9
Обратите внимание, что вам также может понадобиться сменить владельца файлов на root - мне пришлось:compaudit | xargs chown root
Брэд Паркс
4
Это определенно лучшее решение для меня. Я установил zsh и zsh-дополнения с помощью Homebrew, поэтому, очевидно, не хотел менять его на принадлежащий root.
Кэти Лавалле
2
compaudit | xargs chmod g-wвместе с тем ompaudit | xargs chown rootработал и на меня и, казалось, поддерживал HomeBrew. Может кто-нибудь объяснить, что происходит немного больше.
nyxee
76

Большинство ответов приходят с решением, но не упоминают, почему возникает это предупреждение. Вот выдержка из сборника ZSH :

В целях безопасности compinit также проверяет, будет ли система завершения использовать файлы, не принадлежащие пользователю root или текущему пользователю , или файлы в каталогах, которые доступны для записи для всех пользователей или групп, или которые не принадлежат пользователю root или текущему пользователю . Если такие файлы или каталоги найдены, compinit спросит, действительно ли должна использоваться система завершения. Чтобы избежать этих тестов и заставить все найденные файлы использоваться без запроса, используйте опцию -u, а для того, чтобы compinit беззвучно игнорировал все небезопасные файлы и каталоги, используйте опцию -i. Эта проверка безопасности полностью пропускается, если задана опция -C.

Следовательно, решение подразумевает исправление одного (или всех) из следующего:

  • установка текущего пользователя как владельца всех каталогов / подкаталогов / файлов по причине:

    compaudit | xargs chown -R "$(whoami)"
    
  • удаление прав на запись для группы / других для файлов в причинах:

    compaudit | xargs chmod go-w
    

Другой подход - пропустить эти проверки, используя

compinit -u

но я не очень рекомендую это, поскольку скрытие проблем под ковриком решает проблемы в краткосрочной перспективе.

linkyndy
источник
1
Спасибо. Я поражен тем, что люди произвольно набирают команды без реального понимания проблемы.
визг
3
Как насчет многопользовательской системы? В таком случае chown -R "$(whoami)"для файлов вне домашнего каталога, таких как /usr/local/не будет работать. Согласно документам, не имеет ли смысла делать файлы принадлежащими корню?
goetzc
Мне нравится этот ответ лучше всего. Заставил меня задуматься о том, почему это случилось со мной. Оказывается, это произошло после добавления другого пользователя в основную группу моего пользователя. Каталоги в $ HOME / .antigen / bundles принадлежали моему пользователю и моей группе. Так что в моем случае удаление этого пользователя из группы решило проблему.
Самуил
25

Я получил те же предупреждения, когда я sudo -i запускал корневую оболочку, , решение @ chakrit у меня не сработало.

Но я нашел -uпереключатель compinitработ, например, в вашем .zshrc / zshenv или где вы звонилиcompinit

compinit -u

Примечание: не рекомендуется для производственной системы

Смотрите также http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization

number5
источник
это было единственное решение, которое работало на меня. я пытался использовать zsh с compinit на подсистеме Linux на Windows 10
Деннс
17

Это работает для моего Mac после обновления до High Sierra.

Удалить доступ для записи группы:

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

Лучше всего, чтобы изменение было ограничено каталогами zsh.

Хэнк Чан
источник
1
sudo chmod gw / usr / local / share / zsh / site-functions (работал для меня в mac 10.15)
shijin
2
Это было единственное исправление, которое работало для меня на Mac Catalina
user8467470
1
Это исправление работало для меня на MacOS Catalina. Спасибо!
Тайлер
12

Принятый ответ не работал для меня на MacOs Sierra (10.12.1). Пришлось сделать это рекурсивно из / usr / local

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

Примечание: вы можете получить свое имя пользователя с помощью whoamiи вашу группу с помощьюid -g

Франко
источник
4
На Сьерре я тоже так не делал, хотя в многопользовательской системе правильный пользователь / группа должен быть пользователем root: staff
Marshall
5

Эти две строки исправили для меня.

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

sudo chown -R _user_:root /usr/local/share/zsh/*
arglee
источник
3
Работа для меня! Я использую сетевую учетную запись на моем компьютере - Ubutun 16.04 sudo chown -R $(whoami):root /usr/local/share/zsh sudo chown -R $(whoami):root /usr/local/share/zsh/*
hoangdv
5

На macOS Sierra вам нужно запустить: sudo chown -R $(whoami):staff /usr/local

kkodev
источник
4

Я исправил это, делая

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

в моем случае другие каталоги внутри share / также имеют группу «staff»

Franck
источник
Вопрос не по теме переполнения стека, как определено в справочном центре . Пожалуйста, не отвечайте на такие вопросы; вместо этого вы должны отметить их для внимания, и они будут закрыты или перенесены соответствующим образом.
Тоби Спейт
4

на Мохаве, это добилось цели: sudo chmod go-w /usr/local/share

Себастьен Х.
источник
1
Еще лучше:sudo chmod -R go-w /usr/local/share
экманавт
3

Я предлагаю запустить compaudit, а затем просто исправить разрешения для каталогов, найденных аудитом. Убедитесь, что указанные каталоги не имеют разрешений на запись для группы или других.

Tiamot
источник
3

Моя машина:

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

Итак, вот что я сделал,

  1. запустить, compauditи он даст вам список каталогов, которые он считает небезопасными.

  2. запустить sudo chmod -R 755 target_directory (пример: sudo chmod -R 755 /usr/local/share/zsh)

Exmaple:

compaudit

возвращает:

/ USR / местные / доли / ЗШ

так я бегу

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

читать больше здесь ссылка

Султанмырза Касымбеков
источник
2

Этим утром некоторые пакеты в моей системе обновились и оставили мне это сообщение об ошибке. Я использую Ubuntu 18.04.

Очевидно, что-то в обновлении изменило имя пользователя и группу на числа 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

Я просто изменил пользователя и группу для этого файла обратно, rootи проблема исчезла. Мне не нужно было менять какие-либо разрешения, и я бы предостерегал против этого, если не будет понята основная причина проблемы.

sudo chown root _code && sudo chgrp root _code

После переключения 131и 142обратно на rootэто сообщение об ошибке от zsh ушло.

Тодд
источник
2
  1. запустить, compauditи он даст вам список каталогов, которые он считает небезопасными

  2. sudo chown -R username:root target_directory

  3. sudo chmod -R 755 target_directory

Шариф Мухаммед Юнус
источник
2

В последнее время у меня было такое же предупреждение о Каталине. Простой обходной путь - поместить это на вершину вашего .zshrc

ZSH_DISABLE_COMPFIX=true
Фредерик
источник
1

Запуск этой команды работал для меня на моем mac OS Catalina:

compaudit | xargs chmod g-w,o-w

Мигель Хулио
источник
1

Решение MAC OS X:

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

Также "user: staff = пользователь root по умолчанию в OSX.

jpmottin
источник