xxh / xxh-plugin-zsh-ohmyzsh

Oh my zsh plugin for xxh zsh
BSD 2-Clause "Simplified" License
38 stars 20 forks source link

ohmyzsh complains about insecure directories #3

Closed fdellwing closed 4 years ago

fdellwing commented 4 years ago

Local OS (where xxh is installed): Kubuntu 18.04 Destination host OS: Debian 9 xxh version: 0.8.5 xxh-plugins installed: xxh-plugin-zsh-ohmyzsh

Steps to Reproduce

  1. I run xxh +s zsh icinga2 with another uid as the user you will connect to.
  2. The output log:
    
    [oh-my-zsh] Insecure completion-dependent directories detected:
    drwxrwxr-x  11 1000 1000  4096 Sep 22 15:45 /root/.xxh/.xxh/plugins/xxh-plugin-zsh-ohmyzsh/build/ohmyzsh
    drwxrwxr-x 282 1000 1000 12288 Sep 22 15:45 /root/.xxh/.xxh/plugins/xxh-plugin-zsh-ohmyzsh/build/ohmyzsh/plugins
    drwxrwxr-x   2 1000 1000  4096 Sep 22 15:45 /root/.xxh/.xxh/plugins/xxh-plugin-zsh-ohmyzsh/build/ohmyzsh/plugins/git

[oh-my-zsh] For safety, we will not load completions from these directories until [oh-my-zsh] you fix their permissions and ownership and restart zsh. [oh-my-zsh] See the above list for directories with group or other writability.

[oh-my-zsh] To fix your permissions you can do so by disabling [oh-my-zsh] the write permission of "group" and "others" and making sure that the [oh-my-zsh] owner of these directories is either root or your current user. [oh-my-zsh] The following command may help: [oh-my-zsh] compaudit | xargs chmod g-w,o-w

[oh-my-zsh] If the above didn't help or you want to skip the verification of [oh-my-zsh] insecure directories you can set the variable ZSH_DISABLE_COMPFIX to [oh-my-zsh] "true" before oh-my-zsh is sourced in your zshrc file.

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


3. What is the problem:
You should either set `ZSH_DISABLE_COMPFIX` to true before loading the shell or (better) make sure the folders and files are owned by the user you connect to.

**For community:**
⬇️  **Please click the 👍 reaction instead of leaving a `+1` or 👍  comment**
anki-code commented 4 years ago

Hello @fdellwing! Thank you for reporting this. Could you provide more details about this situation. If we upload the files using UID/GID the user who connect to how another uid appeared?

fdellwing commented 4 years ago

I can only assume, that the method that uploads ohmyzsh to the remote server, preserves the original UID/GID from the local files.

I do connect from a non priviledges shell with a default Ubuntu user (1000:1000) to a default Debian 9 root session (0:0).

anki-code commented 4 years ago

preserves the original UID/GID from the local files.

Nope, the files will be created on the host with uid/gid of the user who connect to. Ordinarily if you have local user foo and you connect to the host as user bar then your .xxh directory on the server will have bar:bar permissions. In your case I think we have not so standard situation so I recommend deep dive into the permissions logic. Maybe your server has custom settings for the default permissions.

You should either set ZSH_DISABLE_COMPFIX to true before loading the shell or (better) make sure the folders and files are owned by the user you connect to.

Because we have the first case with this let's solve it locally. Put ZSH_DISABLE_COMPFIX=true to xxh environment variables for your host or fork this repo and customize.

fdellwing commented 4 years ago

The .xxh directory does have 0:0, the wrong permissions start deeper down in the folder structur. I'll provide more details once I'm back at my linux client tomorrow.

fdellwing commented 4 years ago

I switched to another method to use zsh remotely. Closing this.

anki-code commented 4 years ago

@fdellwing could you please share this method?

fdellwing commented 4 years ago

I'm using a remotely installed zsh with

RequestTTY yes
RemoteCommand zsh

set in my ssh config. A lot more work to setup on remote side, but works much better for my needs.