0

I am seeing zsh compinit: insecure directories and files when I run compinit. Yes, I have seen this SO post and this U&L post, as well as all sorts of related posts. For all of those examples, the solution is to remove write permissions from group and world. However, in my case the offending directories are not writable by group nor world.

$ compaudit
There are insecure directories and files:
/path/to/modules/init/zsh-functions
/path/to/modules/init
/path/to/modules/init/zsh-functions/_module
$ ll /path/to/modules
...
drwxr-sr-x 4 theuser thegroup 4.0K Feb  6  2020 init/
...
$ ll /path/to/modules/init
...
drwxr-sr-x 2 theuser thegroup 4.0K Feb  6  2020 zsh-functions/
...
$ ll /path/to/modules/init/zsh-functions
...
-rw-r--r-- 1 theuser thegroup 12K Feb  6  2020 _module
...

The two directories do have the SGID bit set, but nowhere have I seen that its presence will cause this warning. Further, the final path is a file, which does not have the SGID bit set.

These paths are not owned by me, but they are in a group to which I belong.

If it matters, these directories are for environment modules.

Can I get some pointers on how I can solve this issue, hopefully without just disabling the insecure check?

SethMMorton
  • 270
  • 1
  • 10
  • And are you `theuser`? – Stéphane Chazelas Apr 06 '21 at 06:12
  • @StéphaneChazelas No, I am not. – SethMMorton Apr 06 '21 at 06:33
  • That would be it. It tells you those areas are writable by another user, so they can make you run anything. – Stéphane Chazelas Apr 06 '21 at 06:35
  • @StéphaneChazelas So I am working in a multi-user environment where these directories are owned by an administrative account. Surely this is a situation thought of by the zsh authors and there is a way to “trust” these directories, correct? – SethMMorton Apr 06 '21 at 06:38
  • 1
    Looking at the code, it accepts `$fpath` dirs owned by the same user as the `zsh` executables, but doesn't seem to allow explicitely whitelisting users. You can always modify the function, though it seems here the best course of action would be to make sure the files are owned by root which would be better practice. – Stéphane Chazelas Apr 06 '21 at 07:15
  • @StéphaneChazelas In principle, having it be owned by root is probably "correct". Unfortunately, I am in an enterprise environment with hundreds (thousands?) of users, and only a handful of the IT engineers have root access. This location is user-installed using a faceless account, and if we ask that it get changed to root we lose our ability to self-maintain without filing a ticket and waiting however long to get the ticket answered. Anyway - all that is to say that it sounds like standard solutions won't work here. – SethMMorton Apr 06 '21 at 16:44
  • So, is the only solution then to disable the insecure check when running `compinit`? Or, perhaps "modifying the function" as you mention - what does that mean? – SethMMorton Apr 06 '21 at 16:44

0 Answers0