zsh compinit：不安全的目录[关闭]答案

【问题标题】：zsh compinit: insecure directories [closed]zsh compinit：不安全的目录[关闭]
【发布时间】：2012-11-25 14:00:36
【问题描述】：

这是什么意思，我该如何解决？

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

【问题讨论】：

有人知道为什么会出现这个警告吗？
@Blaszard 提出有效问题一年后（作为评论），“linkyndy”在下面回答（作为答案）。

标签： zsh zsh-completion

【解决方案1】：

这为我解决了问题：

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

信用：a post on zsh mailing list

编辑： 正如@biocyberman 在 cmets 中指出的那样。您可能还需要更新site-functions 的所有者：

$ sudo chown -R root:root /usr/local/share/zsh/site-functions

在我的机器 (OSX 10.9) 上，我不需要这样做，但 YMMV。

EDIT2：在 OSX 10.11 上，只有这个有效：

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

另外 user:staff 是 OSX 上正确的默认权限。

【讨论】：

@kirill_igum “无根”是指“无根访问”吗？如果是这样，那么您应该将文件复制到您有权访问的文件夹中，修复您的 .zshenv 和 .zshrc 以使用新文件夹并在新文件夹上执行相同的 chmod，就像我在文件夹中发布的那样.
我注意到在将所有者设置为 root 后，需要撤销组和其他组的写入权限。我将chmod 命令修改为sudo chmod -R go-w zsh。
注意：我在 /usr/local/share/zsh/site-functions 中有符号链接到 /usr/local/Cellar 并且在此之前也必须到 chown -R root:staff /usr/local/Cellar。
这并没有解决它。
这个答案对我不起作用。以下compaudit 的答案对我有用。

【解决方案2】：

删除组写入权限

compaudit | xargs chmod g-w

会成功的。

见http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/

【讨论】：

就是这样！删除组的写入权限。谢谢
更好的答案，应该注意compaudit 可用于诊断和修复此类问题。
请注意，您可能还必须将文件的所有者更改为 root - 我必须：compaudit | xargs chown root
这对我来说绝对是最好的解决方案。我用 Homebrew 安装了 zsh 和 zsh-completions，所以显然不想将其更改为由 root 拥有。
compaudit | xargs chmod g-w 和 ompaudit | xargs chown root 也为我工作，似乎让 HomeBrew 很开心。有人可以解释一下发生了什么。

【解决方案3】：

大多数答案都有解决方案，但不要提及为什么会出现此警告。以下是 ZSH 的compinit 的摘录：

出于安全原因，compinit 还会检查完成系统是否会使用 不属于 root 或当前用户的文件，或者 目录中的文件是全局可写或组可写或不属于 root 或当前用户。如果找到这样的文件或目录，compinit 将询问是否真的应该使用完成系统。要避免这些测试并使所有找到的文件无需询问即可使用，请使用选项 -u，并让 compinit 静默忽略所有不安全的文件和目录，请使用选项 -i。给出 -C 选项时会完全跳过此安全检查。

因此，解决方案意味着修复以下一项（或全部）：

将当前用户设置为原因中所有目录/子目录/文件的所有者：
```
compaudit | xargs chown -R "$(whoami)"
```
删除组/其他人对原因文件的写入权限：
```
compaudit | xargs chmod go-w
```

另一种方法是通过使用跳过这些检查

compinit -u

但我并不是真的建议这样做，因为隐藏问题只能在短期内解决问题。

【讨论】：

谢谢。我很惊讶人们会在没有真正理解问题的情况下随机输入命令。
多用户系统怎么样？在这种情况下，chown -R "$(whoami)" 用于主目录之外的文件，例如 /usr/local/ 将不起作用。根据文档，将文件设为 root 拥有不是更有意义吗？
我最喜欢这个答案。让我思考为什么这会发生在我身上。原来它是在将另一个用户添加到我的用户的主组之后发生的。 $HOME/.antigen/bundles 下的目录归我的用户和我的组所有。所以在我的情况下，从组中删除该用户解决了这个问题。
删除组和其他人的写权限有助于为我解决问题！谢谢！
这是几十个答案中前三个左右的答案之一。与其他几个很好的答案一样，它解释了发生的事情并提供了解决方案。

【解决方案4】：

一旦您了解原因，解决方案微不足道且明确。

原因：compaudit 输出的目录具有 group 或 others 的 write 权限（世界- 可写）；或者这些文件由 root 或您自己以外的其他人拥有。
示例：就我而言，compaudit 给了我：

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

如果我们列出我们拥有的那些文件/目录的权限（在这种情况下）

% ls -lh /usr/local/share 
total 0
drwxr-xr-x  12 chbrandt  admin   384B Aug 14 10:45 aclocal
drwxr-xr-x   8 chbrandt  admin   256B Aug 14 10:45 doc
drwxr-xr-x   3 chbrandt  admin    96B Jul 24 21:00 fish
lrwxr-xr-x   1 chbrandt  admin    36B Aug 14 10:45 gettext -> ../Cellar/gettext/0.21/share/gettext
lrwxr-xr-x   1 chbrandt  admin    41B Aug 14 10:45 gettext-0.21 -> ../Cellar/gettext/0.21/share/gettext-0.21
lrwxr-xr-x   1 chbrandt  admin    37B Aug 14 10:45 gtk-doc -> ../Cellar/libidn2/2.3.0/share/gtk-doc
drwxr-xr-x   9 chbrandt  admin   288B Aug 14 10:45 info
drwxr-xr-x  58 chbrandt  admin   1.8K Aug 14 10:45 locale
lrwxr-xr-x   1 chbrandt  admin    41B Jul 27 17:12 luajit-2.0.5 -> ../Cellar/luajit/2.0.5/share/luajit-2.0.5
drwxr-xr-x   5 chbrandt  admin   160B Jul 27 17:12 man
lrwxr-xr-x   1 chbrandt  admin    33B Aug 14 10:45 nvim -> ../Cellar/neovim/0.4.4/share/nvim
drwxrwxr-x   3 chbrandt  admin    96B Jul 24 20:57 zsh
%
% ls -lh /usr/local/share/zsh 
total 0
drwxrwxr-x  4 chbrandt  admin   128B Jul 24 21:00 site-functions
%
% ls -lh /usr/local/share/zsh/site-functions 
total 0
lrwxr-xr-x  1 chbrandt  admin    39B Jul 24 21:00 _brew -> ../../../Homebrew/completions/zsh/_brew
lrwxr-xr-x  1 chbrandt  admin    44B Jul 24 21:00 _brew_cask -> ../../../Homebrew/completions/zsh/_brew_cask

现在我们很容易发现问题，不是吗？注意zsh/ 和zsh/site-functions 目录与其他目录的不同... zsh 不喜欢允许admin 组修改它们的'w'。

解决方案：关闭group-writable权限！

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

就是这样！你可以走了。打开一个新终端，您应该不再看到“zsh compinit: insecure directories”消息；）

【讨论】：

这是最好的答案。给这些人点个赞。谢谢你摇滚的详细勃兰特
什么通常会导致这些目录的这些权限发生变化？
@JaapWijnen 我不认为它们被更改，那些目录可能是这样创建的。我什至不认为这是一个错误（如果您考虑整个环境并且chbrandt 是“su”而admin 是优先组等等......）。特别是在这种情况下——现在回答你的问题——那些“错误”的权限是/可能是 zsh/homebrew 领域中的一个小错误的结果......或者一个被误解的功能；）
这是最好的答案，因为它解释了问题，并在应用解决方案时展示了一个真实的具体示例
@Brandt 我尝试应用您建议的更改，但错误仍然存在，我发布了一个单独的问题apple.stackexchange.com/questions/431861/…

【解决方案5】：

自从 High Sierra 更新以来，这适用于我的 Mac。

删除组写入权限：

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

最好将更改限制在 zsh 目录中。

【讨论】：

sudo chmod g-w /usr/local/share/zsh/site-functions（在 mac 10.15 中为我工作）
这是在 Mac Catalina 上对我有用的唯一修复
这个修复在 MacOS Catalina 上也适用于我。谢谢！

【解决方案6】：

此命令更新所有具有正确权限的文件/文件夹：

compaudit | xargs chmod g-w

您不需要使用sudo 来更改所有者 - 除非文件属于 root

（在 macOS BigSur 上测试）

【讨论】：

唯一对我有用的答案。

【解决方案7】：

当我sudo -i 启动 root shell 时，我收到了同样的警告，@chakrit 的解决方案对我不起作用。

但是我发现compinit 的-u 开关有效，例如在你的 .zshrc/zshenv 或者你打电话给compinit的地方

compinit -u

【讨论】：

这是唯一对我有用的解决方案。我试图在 Windows 10 上的 linux 子系统上使用 zsh 和 compinit
对我不起作用。

【解决方案8】：

这个答案主要是供我自己将来使用的参考，因为大多数答案都没有提供完整的解决方案。这里是：

第一次运行：

compinit

如果上述方法不起作用，请使用compaudit

对于打印的每条路径，运行以下命令：

sudo chown $(whoami) PATH_HERE

sudo chmod -R 755 PATH_HERE

简单的例子，假设运行 compinit 后打印的路径之一是“/usr/local/share/zsh”。那么：

sudo chown $(whoami) /usr/local/share/zsh

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

【讨论】：

只是运行sudo chown $(whoami) PATH_HERE 为我工作。谢谢！

【解决方案9】：

我最近在 Catalina 上也收到了同样的警告。一个简单的解决方法是将它放在 .zshrc 的顶部

ZSH_DISABLE_COMPFIX=true

【讨论】：

这是在 macOS Catalina 10.15.5 上帮助我的唯一解决方案！ compaudit | xargs chmod go-w 或 compinit -u 之类的所有其他内容似乎不适用于此版本的 macOS
这是唯一适用于 MacOS Catalina 10.15.5 @Deliaz 谢谢@FredericK !!!
唯一适用于 macOS BigSur 11.2.1 (20D74) 的解决方案。非常感谢。

【解决方案10】：

在 macOS Sierra (10.12.1) 上，接受的答案对我不起作用。必须从 /usr/local 递归

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

注意：您可以使用whoami 获取您的用户名，使用id -g 获取您的群组

【讨论】：

我在 Sierra 上也没有这样做，尽管在多用户系统上正确的用户/组应该是 root:staff

【解决方案11】：

在我的mac OS Catalina 上运行此命令对我有用：

compaudit | xargs chmod g-w,o-w

【讨论】：

只有这个 compaudit | xargs chmod g-w 为我工作。

【解决方案12】：

我的机器：

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

这就是我所做的，

运行compaudit，它会给你一个它认为不安全的目录列表。
运行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

在此处阅读更多信息link

【讨论】：

这对我来说在 Big Sur 上非常有效
对我不起作用。

【解决方案13】：

MAC OS X 解决方案：

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

还有“user:staff = OSX 上的默认 root 用户。

【讨论】：

对我不起作用。
这种评论没有帮助，你没有指出一个特定的问题，或者添加额外的信息，澄清@KoenigLear，甚至要求精确。如果每个人都这样做，这将是一团糟。
我完全按照说明应用了这些步骤，但恐怕它们不起作用。错误仍然存在。如果有任何其他消息，我会提到它。我也提供答案并对任何反馈感到满意。

【解决方案14】：

在过去的几个月里，我遇到了这个问题，我尝试了几件事，但没有奏效。最后帮助我的是这个。获取不安全目录的列表，然后按如下所述设置所有目录的 chmod。

CLI# compaudit
There are insecure directories:
/usr/local/share/zsh
CLI# sudo chmod -R 755 /usr/local/share/zsh
Password:

【讨论】：

没有帮助我。

【解决方案15】：

我修好了

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

在我的情况下，share/ 中的其他目录也分配了“员工”组

【讨论】：

【解决方案16】：

这两行对我来说是固定的。

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

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

【讨论】：

为我工作！我在我的电脑上使用网络帐户 - Ubutun 16.04 sudo chown -R $(whoami):root /usr/local/share/zsh sudo chown -R $(whoami):root /usr/local/share/zsh/*
...如果你有指向其他地方的符号链接，你也需要 chown 那些

【解决方案17】：

在莫哈韦沙漠，这成功了： sudo chmod go-w /usr/local/share

【讨论】：

更好的是：sudo chmod -R go-w /usr/local/share
/usr/local/share/zsh 就够了。
对我不起作用。

【解决方案18】：

这是https://github.com/zsh-users/zsh-completions/issues/433#issuecomment-600582607 唯一对我有用的东西。谢谢https://github.com/malaquiasdev！

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

【讨论】：

【解决方案19】：

以下在 M1 上工作

ProductName:    macOS
ProductVersion: 11.1
BuildVersion:   20C69

% compaudit
/opt/homebrew/share

将群组权限从 775 更改为 755

% sudo chmod 755 /opt/homebrew/share

drwxr-xr-x   33 xenea  admin   1056 Feb  2 01:28 share

【讨论】：

也在运行 OS 11.2 的非 M1 MBP 2019 上工作

【解决方案20】：

在 macOS Sierra 上，您需要运行： sudo chown -R $(whoami):staff /usr/local

【讨论】：

对我不起作用。

【解决方案21】：

我的建议是运行 compaudit，然后只修复审计发现的目录的权限。确保识别的目录没有组或其他的写入权限。

【讨论】：

【解决方案22】：

运行compaudit，它会给你一个它认为不安全的目录列表
sudo chown -R username:root target_directory
sudo chmod -R 755 target_directory

【讨论】：

【解决方案23】：

今天早上，我系统中的一些软件包更新了，并给我留下了这个错误消息。我正在使用 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 的此错误消息消失了。

【讨论】：

【解决方案24】：

我在运行google-cloud-sdk 安装脚本后遇到了这个问题，该脚本通过.zshrc 中的条目将命令完成添加到shell。

关注Homebrew's instructions for configuring completions in zsh 很有帮助。

此外，如果您在尝试加载这些补全时收到“zsh compinit: insecure directory”警告，您可能需要运行以下命令：chmod -R go-w "$(brew --prefix)/share"

【讨论】：

@DavidJ。其实这个答案真的很有用。

【解决方案25】：

我没有看到任何引用 homebrew 有关此主题的信息的答案：https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh

要使 Homebrew 的完成功能在 zsh 中可用，在初始化 zsh 的完成功能之前，您必须在 FPATH 上获取 Homebrew 管理的 zsh 站点功能。将以下内容添加到您的 ~/.zshrc 文件中：

if type brew &>/dev/null; then
  FPATH=$(brew --prefix)/share/zsh/site-functions:$FPATH

  autoload -Uz compinit
  compinit
fi

这必须在调用 compinit 之前完成。

这解决了我without 手动更改所有权或其他方式的问题。

【讨论】：

我在 Big Sur @r3wt

【解决方案26】：

列出的解决方案都不适合我。相反，我最终卸载并重新安装了 Homebrew，这成功了。卸载说明可以在这里找到：http://osxdaily.com/2018/08/12/how-uninstall-homebrew-mac/

【讨论】：

【解决方案27】：

使用compinit 向脚本的输入流发送一个y 字符，以便自动回答忽略不安全的目录和文件并继续[y] 或中止compinit [n]？ 问题

echo "y" > source <GOOGLECLOUDSDK>/completion.zsh.inc

解决方案在以下情况下很有用

您无法更改文件夹的所有权/访问权限
当您无法使用 -u 选项删除警告时（可能是因为您自己没有显式调用“compinit”，而是由您调用的脚本调用）

备注：它不能解决问题，只会隐藏警告（与此处涉及删除“组写入访问”或“将所有权更改为 root”的其他答案相反）。 p>

【讨论】：

【解决方案28】：

我尝试了所有发布的解决方案，最后没有一个适用于我的特殊情况。但是，我要感谢那些向我指出所有权方向的用户，这是关于多个帐户的真正问题，而不是模式。我正在为具有类似设置（M1 + 两个帐户 + /opt/homebrew/share）的其他任何人发布此答案。

这是我的设置：

我有一台 M1，运行 macOS Monterey 12.0.1，使用 Homebrew。

我有两个帐户，一个管理员和一个普通用户（工作需要拆分）。我只有普通用户的不安全目录问题，两个用户都使用相同的自制设置，以下目录和文件受到问题的影响：

/opt/homebrew/completions/zsh/_brew
/opt/homebrew/share/zsh
/opt/homebrew/share/zsh/site-functions
/opt/homebrew/share/zsh/site-functions/_brew
/opt/homebrew/share/zsh/site-functions/_brew_services
/opt/homebrew/share/zsh/site-functions/_cargo
/opt/homebrew/share/zsh/site-functions/_gh
/opt/homebrew/share/zsh/site-functions/_git
/opt/homebrew/share/zsh/site-functions/_j
/opt/homebrew/share/zsh/site-functions/_lf
/opt/homebrew/share/zsh/site-functions/_task
/opt/homebrew/share/zsh/site-functions/_tldr
/opt/homebrew/share/zsh/site-functions/_vifm

更改模式没有任何效果，最终解决问题的方法是将每个问题文件和目录的所有权更改为 root:admin，如下所示：

sudo chown root:admin /opt/homebrew/share/zsh/site-functions/*

最初，在问题出现之前，我的管理员用户拥有一切，因此所有权看起来像这样：usr:admin

这就是 site-functions 目录现在的样子，没有问题：

lrwxr-xr-x  1 root admin  30 Jul 19 19:41 _brew ->../../../completions/zsh/_brew
lrwxr-xr-x  1 root admin  79 Aug 10 20:26 _brew_services -> ../../../Library/Taps/homebrew/homebrew-services/completions/zsh/_brew_services
lrwxr-xr-x  1 root admin  59 Nov  6 16:28 _cargo -> ../../../Cellar/rust/1.56.1/share/zsh/site-functions/_cargo
lrwxr-xr-x  1 root admin  53 Dec  2 23:37 _gh -> ../../../Cellar/gh/2.3.0/share/zsh/site-functions/_gh
lrwxr-xr-x  1 root admin  56 Nov 30 15:21 _git -> ../../../Cellar/git/2.34.1/share/zsh/site-functions/_git
lrwxr-xr-x  1 root admin  61 Oct 13 11:12 _j -> ../../../Cellar/autojump/22.5.3_3/share/zsh/site-functions/_j
lrwxr-xr-x  1 root admin  50 Oct 23 18:52 _lf -> ../../../Cellar/lf/26/share/zsh/site-functions/_lf
lrwxr-xr-x  1 root admin  57 Nov  6 16:28 _task -> ../../../Cellar/task/2.6.1/share/zsh/site-functions/_task
lrwxr-xr-x  1 root admin  57 Nov 18 01:45 _tldr -> ../../../Cellar/tldr/1.4.2/share/zsh/site-functions/_tldr
lrwxr-xr-x  1 root admin  56 Oct 13 11:11 _vifm -> ../../../Cellar/vifm/0.12/share/zsh/site-functions/_vifm

【讨论】：