这意味着什么?我该如何解决?

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

注:此答案为2012年数据。


这为我解决了问题:

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

出处:zsh邮件列表上的一个帖子


编辑:正如@biocyberman在评论中指出的那样。您可能还需要更新站点函数的所有者:

$ 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上正确的默认权限。


当我sudo -i启动根shell时,我得到了相同的警告,@chakrit的解决方案对我不起作用。

但我发现-u开关的compinit工作,例如在你的.zshrc/zshenv或你调用compinit的地方

compinit -u

注意:不建议用于生产系统

参见http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization


删除组写权限

compaudit | xargs chmod g-w

会成功的。

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


接受的答案在macOs Sierra(10.12.1)上不适用。必须从/usr/local递归吗

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

注意:你可以用whoami获取你的用户名,用id -g获取你的组


这两条线路已经为我固定了。

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

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

大多数答案都提供了解决方案,但没有提到为什么会出现这种警告。以下是ZSH公司的一段摘录:

For security reasons compinit also checks if the completion system would use files not owned by root or by the current user, or files in directories that are world- or group-writable or that are not owned by root or by the current user. If such files or directories are found, compinit will ask if the completion system should really be used. To avoid these tests and make all files found be used without asking, use the option -u, and to make compinit silently ignore all insecure files and directories use the option -i. This security check is skipped entirely when the -C option is given.

因此,解决方案意味着解决以下一个(或所有)问题:

将当前用户设置为所有目录/子目录/文件的所有者,原因如下: compaudit | xargs chown -R "$(whoami)" 删除组/others文件的写权限,原因如下: Compaudit | xargs chmod go-w

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

compinit -u

但我并不建议这样做,因为把问题藏在地毯下只能在短期内解决问题。


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


我通过做来解决它

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

在我的例子中,share/中的其他目录也分配了“staff”组


这适用于我的Mac,因为High Sierra更新。

取消组写权限:

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

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


在莫哈韦沙漠,这招奏效了: Sudo chmod go-w /usr/local/share

(2022年更新)

如果使用ZSH补全,你应该使用chmod -R go-w "$(brew——prefix)/share"


今天早上,我的系统中的一些包更新了,并给我留下了这个错误消息。我使用的是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切换回根目录后,来自zsh的错误消息消失了。


上面列出的解决方案没有一个对我有效。相反,我最终卸载并重新安装了Homebrew,这很管用。卸载说明可以在这里找到:http://osxdaily.com/2018/08/12/how-uninstall-homebrew-mac/


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


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


这是我在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

我最近在卡特琳娜也收到了同样的警告。 一个简单的解决方法是将其放在.zshrc的顶部

ZSH_DISABLE_COMPFIX=true

在我的mac OS Catalina上运行这个命令是有效的:

Compaudit | xargs chmod g-w,o-w


我的机器:

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

点击这里阅读更多链接


MAC OS X解决方案:

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

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


我在运行google-cloud-sdk安装脚本后得到了这个问题,该脚本通过.zshrc中的一个条目将命令补全添加到shell中。

按照Homebrew的说明在zsh中配置补全是有帮助的。

此外,如果你在尝试加载这些补全时收到" zsh compinit: insecure directories "警告,你可能需要运行这个:chmod -R go-w "$(brew——prefix)/share"


这个答案主要是我自己在未来使用的参考,因为大多数答案都没有提供一个成熟的解决方案。下面就是:

第一次运行:

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

一旦你了解了原因,解决方案是微不足道的和明确的。

原因:compaudit输出的目录有group或other写权限(world-writable);或者这些文件属于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不支持允许管理组修改它们的“w”。

解决方案:关闭组可写权限!

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

就是这样!你可以出发了。打开一个新终端,你应该不会再看到“zsh compinit: insecure directories”消息了;)


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

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

解决方案是有用的

不能对文件夹进行所有权/访问更改 当你不能使用-u选项来删除警告时(可能是因为你自己没有显式地调用'compinit',但它是由你调用的脚本调用的)

备注:它不会修复问题,只是隐藏了警告(与这里涉及删除“组写访问权限”或“更改所有权到根”的其他答案相反)。


在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

更新所有权限正确的文件/文件夹:

Compaudit | xargs chmod g-w

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

(在macOS BigSur上测试)


我没有看到任何关于这个主题的自制信息的回答:https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh

要使Homebrew的完成功能在zsh中可用,必须在初始化zsh的完成功能之前在FPATH上获得Homebrew管理的zsh site-functions。将以下内容添加到~/。zshrc中:

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

  autoload -Uz compinit
  compinit
fi

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

这为我解决了问题,无需手动更改所有权或其他方式。


我得到这个问题在过去的5个月尝试了一些事情,但没有工作。最后帮助我的是这个。获取不安全目录的列表,然后按照下面的描述设置所有这些目录的chmod。

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

我尝试了张贴的每一个解决方案,最后没有一个适合我的特殊情况。然而,我想向那些向我指出所有权是多账户真正问题的用户表示感谢,而不是模式。 我把这个答案发布给其他有类似设置的人(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

这是站点功能目录现在的样子,没有问题:

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