zsh compinit: directorios inseguros [cerrado]

Esto me lo arregló:

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

Créditos: una publicación en la lista de correo zsh

EDIT: Como lo señaló @biocyberman en los comentarios. Es posible que deba actualizar el propietario de site-functions también:

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

En mi máquina (OSX 10.9), no necesito hacer esto sino YMMV.

EDIT2: En OSX 10.11, solo esto funcionó:

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

También usuario: personal es el permiso predeterminado correcto en OSX.

Eliminación de permisos de escritura en grupo con

compaudit | xargs chmod g-w

hará el truco.

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

La mayoría de las respuestas vienen con una solución, pero no mencione por qué ocurre esta advertencia. Aquí hay un extracto de ZSH compintar:

Por razones de seguridad, compinit también verifica si el sistema de finalización usaría archivos que no son propiedad de root o del usuario actualo archivos en directorios que son de escritura mundial o grupal o que no son propiedad de root o del usuario actual. Si se encuentran dichos archivos o directorios, compinit le preguntará si realmente se debe usar el sistema de finalización. Para evitar estas pruebas y hacer que todos los archivos encontrados se usen sin preguntar, use la opción -u, y para hacer que compinit ignore silenciosamente todos los archivos y directorios inseguros, use la opción -i. Esta comprobación de seguridad se omite por completo cuando se da la opción -C.

Por lo tanto, la solución implica arreglar uno (o todos) de los siguientes:

• establecer al usuario actual como propietario de todos los directorios/subdirectorios/archivos en causa:

  compaudit | xargs chown -R "$(whoami)"
  

• eliminando los permisos de escritura para el grupo/otros para los archivos en causa:

  compaudit | xargs chmod go-w
  

Otro enfoque sería omitir estas comprobaciones utilizando

compinit -u

pero realmente no sugiero esto, ya que esconder los problemas debajo de una alfombra solo resuelve los problemas a corto plazo.

Una vez que entender la causa, la solución es trivial y inequívoco.

• Causar: los directorios generados por compaudit tienen escribir permiso de cualquiera Grupo or otros (de escritura mundial); o esos archivos son propiedad de otra persona que no sea raíz o a ti mismo.

• Ejemplo: En mi caso, compaudit me dio eso:

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

Y si enumeramos el permiso de esos archivos/directorios que tenemos (en este caso)

% 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

Ahora detectamos fácilmente el problema, ¿no? Date cuenta cómo zsh/ y zsh/site-functions directorios difieren de los demás... Eso 'w'permitiendo el admin grupo para modificarlos no es apreciado por zsh.

• Solución: apaga eso grupo-escribible ¡permiso!

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

¡Eso es! Eres bueno para ir. Abre una nueva terminal y deberías no ver el "zsh compinit: insecure directories" mensaje más ;)

Esto funciona para mi Mac desde la actualización de High Sierra.

Eliminar el acceso de escritura del grupo:

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

Es mejor mantener el cambio limitado a los directorios zsh.

Este comando actualiza todos los archivos/carpetas con los permisos correctos:

compaudit | xargs chmod g-w

No necesitas usar sudo para cambiar el dueño - a menos que el archivo pertenezca a la raíz

(Probado en macOS BigSur)

Recibí las mismas advertencias cuando sudo -i al iniciar un shell raíz, la solución de @chakrit no funcionó para mí.

Pero encontré -u interruptor de compinit funciona, por ejemplo, en su .zshrc/zshenv o donde llamó compinit

compinit -u

NB: No recomendado para el sistema de producción

Vea también http://zsh.sourceforge.net/Doc/Release/Completion-System.html#Initialization

Esta respuesta es principalmente una referencia para usar en el futuro, ya que la mayoría de las respuestas no brindan una solución completa. Aquí está:

Primer intento:

compinit

utilizan el compaudit si arriba no funciona

Para cada ruta que se imprima, ejecute los siguientes comandos:

sudo chown $(whoami) PATH_HERE

sudo chmod -R 755 PATH_HERE

Ejemplo simple, digamos que una de las rutas que se imprime después de ejecutar compinit es "/usr/local/share/zsh". Después:

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

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

Últimamente tuve la misma advertencia sobre Catalina. Una solución fácil es poner esto en la parte superior de su .zshrc

ZSH_DISABLE_COMPFIX=true

La respuesta aceptada no me funcionó en macOs Sierra (10.12.1). Tuve que hacerlo recursivo desde /usr/local

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

Nota: Puedes obtener tu nombre de usuario con whoami y tu grupo con id -g

ejecutar este comando funcionó para mí en mi mac OS Catalina:

compaudit | xargs chmod g-w,o-w

Mi maquina:

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

Así que esto es lo que hice

1. corrida compaudit y le dará una lista de directorios que cree que no son seguros.

2. corrida sudo chmod -R 755 target_directory (ejemplo: sudo chmod -R 755 /usr/local/share/zsh)

Ejemplo:

compaudit

devoluciones:

/ usr / local / share / zsh

así que corro

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

leer más aquí aquí

Solución MAC OS X:

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

También "usuario: personal = usuario raíz predeterminado en OSX.

Estuve teniendo este problema durante los últimos meses, probé algunas cosas pero no funcionó. Finalmente lo que me ayudó fue esto. Obtenga la lista de directorios inseguros y luego configure el chmod de todos ellos como se describe a continuación.

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

Lo arreglé haciendo

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

en mi caso, otros directorios dentro de share/ también tienen asignado el grupo "staff"

Estas dos líneas se han fijado para mí.

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

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

en Mojave, esto funcionó: sudo chmod go-w /usr/local/share

[Actualización 2022]

Si usa las terminaciones de ZSH, debe usar chmod -R go-w "$(brew --prefix)/share"

Esto fue lo único que funcionó para mí desde https://github.com/zsh-users/zsh-completions/issues/433#issuecomment-600582607. Gracias https://github.com/malaquiasdev!

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

Siguiente trabajado en M1

ProductName:    macOS
ProductVersion: 11.1
BuildVersion:   20C69

% compaudit
/opt/homebrew/share

Permiso de grupo cambiado de 775 a 755

% sudo chmod 755 /opt/homebrew/share

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

En macOS Sierra necesitas ejecutar: sudo chown -R $(whoami):staff /usr/local

1. corrida compaudit y le dará una lista de directorios que cree que son inseguros

2. sudo chown -R username:root target_directory

3. sudo chmod -R 755 target_directory

Mi sugerencia sería ejecutar compaudit y luego corregir los permisos en los directorios encontrados por la auditoría. Asegúrese de que los directorios identificados no tengan permisos de escritura para grupos u otros.

No veo ninguna respuesta que haga referencia a la homebrew información sobre este tema: https://docs.brew.sh/Shell-Completion#configuring-completions-in-zsh

Para que las finalizaciones de Homebrew estén disponibles en zsh, debe obtener las funciones del sitio zsh administradas por Homebrew en su FPATH antes de inicializar la instalación de finalización de zsh. Agregue lo siguiente a su archivo ~/.zshrc:

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

  autoload -Uz compinit
  compinit
fi

Esto debe hacerse antes de llamar a compinit.

Esto resolvió mi problema without cambiando manualmente la propiedad o de otra manera.

Probé todas las soluciones publicadas, al final ninguna funcionó para mi caso particular. Sin embargo, quiero extender mi gratitud a los usuarios que me indicaron la dirección de la propiedad siendo el problema real con respecto a múltiples cuentas, no el modo. Estoy publicando esta respuesta para cualquier otra persona con una configuración similar (M1 + dos cuentas + /opt/homebrew/share).

He aquí mi arreglo:

Tengo un M1, ejecuto macOS Monterey 12.0.1 y uso Homebrew.

Tengo dos cuentas, una de administrador y otra de usuario normal (se requiere división para el trabajo). Solo tuve el problema de los directorios inseguros en el usuario normal, ambos usuarios usan la misma configuración casera, y los siguientes directorios y archivos se ven afectados por el problema:

/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

Cambiar el modo no hizo nada, al final lo que solucionó los problemas fue cambiar la propiedad de cada archivo problemático y el directorio a root:admin, así:

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

Originalmente, antes de que se presentara el problema, mi usuario administrador era dueño de todo, por lo que la propiedad se veía así: usr:administración

Así es como se ve el directorio de funciones del sitio ahora, sin problemas:

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

Esta mañana, algunos paquetes en mi sistema se actualizaron y me dejaron con este mensaje de error. Estoy usando Ubuntu 18.04.

Aparentemente, algo en la actualización cambió el nombre de usuario y el grupo a números, en lugar de root, como tal:

# 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

Simplemente cambié el usuario y el grupo para este archivo de nuevo a root y el problema se fue. Hice no necesita cambiar ningún permiso, y le advertiría que no lo haga a menos que se comprenda la causa subyacente del problema.

sudo chown root _code && sudo chgrp root _code

Después de cambiar 131 y 142 de nuevo a root, este mensaje de error de zsh desapareció.

Tengo este problema después de ejecutar el google-cloud-sdk install script, que agrega la finalización de comandos al shell a través de una entrada en .zshrc.

Siguiendo Instrucciones de Homebrew para configurar finalizaciones en zsh fue útil.

Además, si recibe advertencias de "zsh compinit: directorios inseguros" al intentar cargar estas finalizaciones, es posible que deba ejecutar esto: chmod -R go-w "$(brew --prefix)/share"

Ninguna de las soluciones enumeradas funcionó para mí. En cambio, terminé desinstalando y reinstalando Homebrew, lo que funcionó. Las instrucciones de desinstalación se pueden encontrar aquí: http://osxdaily.com/2018/08/12/how-uninstall-homebrew-mac/

Enviar una y carácter al flujo de entrada del script usando compinit, para responder automáticamente a la ¿Ignorar directorios y archivos inseguros y continuar [y] o abortar compinit [n]? pregunta

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

La solución es útil cuando

• Usted no puede hacer cambios de propiedad/acceso a las carpetas
• cuando tú no puedo usar la opción -u para eliminar la advertencia (probablemente porque usted mismo no llama explícitamente a 'compinit', pero lo llama un script que llama)

Observación: No soluciona el problema y solo oculta la advertencia (a diferencia de otras respuestas aquí que implican eliminar el 'acceso de escritura grupal' o 'cambiar la propiedad a la raíz').