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

2
Хтось знає, чому виникає таке попередження?
Блазард

3
Через рік після того, як @Blaszard задав дійсне питання (як коментар), "linkyndy" відповів на нього нижче (як відповідь).
Happy Green Kid Naps

Відповіді:


342

Це зафіксувало це для мене:

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

Кредит: публікація в списку розсилки zsh


EDIT: Як вказував @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

Також користувач: персонал є правильним дозволом на OSX.


1
що робити, якщо у вас немає кореня
kirill_igum

2
@kirill_igum під "no root" ви мали на увазі "немає кореневого доступу "? Якщо так, то вам слід скопіювати файли у папку, до якої ви маєте доступ, виправити свою .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

264
compaudit | xargs chmod g-w

зробимо трюк, див. http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/


6
Це воно! Видалення дозволу на запис до групи. Спасибі
glarrain

8
Набагато краща відповідь, слід зазначити, що compauditможна використовувати для діагностики подібних проблем, а також для їх усунення.
Вольф

7
Зауважте, що вам, можливо, доведеться також змінити власника файлів на root, - я повинен був:compaudit | xargs chown root
Бред Паркс

4
Це, безумовно, найкраще рішення для мене. Я встановив zsh та zsh-доповнення з Homebrew, тому очевидно не хотів змінювати його, щоб належати root.
katy lavallee

2
compaudit | xargs chmod g-wразом із ompaudit | xargs chown rootпрацювали для мене теж, і, здавалося б, щоб HomeBrew був щасливим. хтось може пояснити, що відбувається трохи більше.
nyxee

76

Більшість відповідей мають вирішення, але не згадуйте, чому виникає таке попередження. Ось уривок із підручника ZSH :

З міркувань безпеки compinit також перевіряє, чи система завершення використовує файли, які не належать кореневі чи поточному користувачеві , або файли в каталогах, які можуть бути записані у всьому світі або в групі, або які не належать root або поточним користувачем . Якщо такі файли чи каталоги знайдені, compinit запитає, чи дійсно слід використовувати систему завершення. Щоб уникнути цих тестів і змусити всі знайдені файли використовуватись без запитання, скористайтеся опцією -u, а щоб змусити мовчки ігнорувати всі незахищені файли та каталоги, використовуйте опцію -i. Ця перевірка безпеки повністю пропускається, коли надається опція -C.

Отже, рішення передбачає виправлення одного (або всіх) з наступного:

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

    compaudit | xargs chown -R "$(whoami)"
    
  • видалення дозволів на запис для групи / інших для файлів, що викликаються:

    compaudit | xargs chmod go-w
    

Іншим підходом було б пропустити ці перевірки за допомогою

compinit -u

але я насправді цього не пропоную, оскільки приховування проблем під килимом вирішує проблеми лише в короткому періоді.


1
Дякую. Я вражений, що люди випадковим чином набирають команди без фактичного розуміння проблеми.
крик

3
А що з багатокористувацькою системою? У такому сценарії chown -R "$(whoami)"для файлів поза домашнім каталогом такі, /usr/local/які не працювали. Згідно з документами, чи не було б більше сенсу змушувати файли мати root?
goetzc

Мені подобається ця відповідь найкраще. Змусив мене задуматися, чому це сталося зі мною Виявляється, це сталося після додавання іншого користувача до основної групи мого користувача. Каталоги під пакетами $ HOME / .antigen / належали моєму користувачеві та моїй групі. Тож у моєму випадку видалення цього користувача із групи вирішило проблему.
Самуїл

25

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

Але я знайшов -uпереключення compinitтворів, наприклад, у вашому .zshrc / zshenv або там, де ви зателефонувалиcompinit

compinit -u

Примітка: Не рекомендується для виробничої системи

Дивіться також http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization


це був єдиний сутін, який працював на мене. я намагався використовувати ЗШ з compinit на підсистеми Linux на Windows 10
denns

15

Це працює для мого 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-функции (працював для мене в mac 10.15)
shijin

1
Це єдине виправлення, яке працювало для мене на Mac Catalina
користувач8467470

Це виправлення працювало і на 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
Я не мав би це зробити так само і в Сьєррі, хоча в багатокористувацькій системі коректний користувач / група повинен бути кореневим: персонал
Marshall Eubanks

5

Ці два рядки зафіксували мене.

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

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

3
Працюй для мене! Я використовую мережевий обліковий запис на своєму ПК - Ubutun 16.04 sudo chown -R $(whoami):root /usr/local/share/zsh sudo chown -R $(whoami):root /usr/local/share/zsh/*
hoangdv


4

Я це виправив

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

в моєму випадку в інших каталогах, що знаходяться всередині /, також призначається група «персоналу»


Питання не є тематичним для переповнення стека, як визначено у довідковому центрі . Не відповідайте на такі запитання; натомість слід позначити їх для уваги, і вони будуть закриті або перенесені належним чином.
Toby Speight


3

Моя пропозиція полягала б у тому, щоб запустити compudit, а потім просто виправити дозволи на каталоги, знайдені аудитом. Переконайтесь, що визначені каталоги не мають дозволу на запис для групи чи інших.



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:)

Приклад:

compaudit

повертає:

/ usr / local / share / zsh

тому я біжу

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

Жодне із перерахованих рішень не працювало для мене. Натомість я закінчив видалення та перевстановлення Homebrew, що зробило трюк. Інструкції щодо видалення можна знайти тут: http://osxdaily.com/2018/08/12/how-uninstall-homebrew-mac/



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.


Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.