zsh compinit: directorios inseguros [cerrado]

¿Qué significa y cómo puedo solucionarlo?

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

Corriendo el compaudit devuelve lo siguiente:

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

preguntado el 07 de diciembre de 12 a las 11:12

Si no tiene permiso para cambiar la propiedad de las carpetas requeridas como se indica en las respuestas, abra el .zshrc archivo y poner esta línea al principio del archivo ZSH_DISABLE_COMPFIX=true. -

28 Respuestas

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.

Respondido 14 Oct 20, 11:10

@kirill_igum por "sin root" quisiste decir "sin root" el acceso"? Si es así, debe copiar los archivos a una carpeta a la que tenga acceso, arreglar su .zshenv y .zshrc para usar la nueva carpeta y hacer lo mismo chmod en la nueva carpeta como he publicado con la carpeta. - chakra

Me di cuenta de que después de configurar el propietario como root, era necesario revocar el acceso de escritura tanto para el grupo como para el otro. modifiqué el chmod orden a sudo chmod -R go-w zsh. - gdvd

Nota: tenía enlaces simbólicos en /usr/local/share/zsh/site-functions a /usr/local/Cellar y tuve que chown -R root:staff /usr/local/Cellar también antes de que esto funcionara. - mVChr

No aclaro si debe ser root:staff or user:staff para macOS. Confuso. - franklin yu

Esta respuesta no funcionó para mí. La siguiente respuesta con compaudit trabajó para mi. - vinos

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/

Respondido el 31 de diciembre de 21 a las 16:12

Mucho mejor respuesta, cabe señalar que compaudit se puede utilizar para diagnosticar problemas como estos, así como para solucionarlos. - Lobo

Tenga en cuenta que es posible que también tenga que cambiar el propietario de los archivos a root. Tuve que: compaudit | xargs chown root - brad parques

Esta es definitivamente la mejor solución para mí. Instalé zsh y zsh-completions con Homebrew, por lo que obviamente no quería cambiarlo para que fuera propiedad de root. - katy lavallee

compaudit | xargs chmod g-w Junto con ompaudit | xargs chown root funcionó para mí también y pareció mantener feliz a HomeBrew. ¿Alguien puede explicar qué está pasando un poco más? - nyxee

Esto es muy similar a la solución recomendada por Homebrew: docs.brew.sh/Shell-Completion. - Oliver José Ceniza

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.

contestado el 13 de mayo de 19 a las 22:05

Gracias. Me sorprende que la gente escriba comandos al azar sin entender realmente el problema. - grito

¿Qué pasa con un sistema multiusuario? En tal escenario, chown -R "$(whoami)" para archivos fuera del directorio de inicio como /usr/local/ no funcionaría. De acuerdo con los documentos, ¿no tendría más sentido hacer que los archivos sean propiedad de la raíz? - goetzc

Me gusta más esta respuesta. Me hizo pensar por qué me pasó esto a mí. Resulta que sucedió después de agregar otro usuario al grupo principal de mi usuario. Los directorios bajo $HOME/.antigen/bundles eran propiedad de mi usuario y mi grupo. Entonces, en mi caso, eliminar a ese usuario del grupo resolvió el problema. - Samuel

Esta es una de las tres respuestas principales entre docenas. Al igual que las otras pocas respuestas excelentes, explica lo que sucede y ofrece soluciones. - David J.

El cambio de propietario de archivo y el cambio de privilegio de archivo fallan, pero compinit -u curar todo! - Neal.Marlin

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 ;)

respondido 16 nov., 21:20

¿Qué causaría generalmente que estos permisos cambien para estos directorios? - Jaap Wijnen

@JaapWijnen No creo que lo fueran cambiado, esos directorios probablemente creado como eso. Ni siquiera lo considero un error (si piensas en todo el entorno y chbrandt siendo un "su" y admin siendo un grupo privilegiado etcétera etcétera...). En este caso en particular, ahora respondiendo a su pregunta, esos permisos "incorrectos" son/fueron probablemente el resultado de un pequeño error en el ámbito de zsh/homebrew... o una característica mal entendida;) - Brandt

Esta es la mejor respuesta, porque explica el problema y muestra un ejemplo real y concreto al aplicar la solución: Alessio

@Brandt Traté de aplicar los cambios sugeridos pero el error persiste, publiqué una pregunta separada apple.stackexchange.com/questions/431861/… - Koenig Lear

Excelente. Esto resolvió mi problema que estaba teniendo al intentar habilitar la finalización del comando aws cli en zsh. Si quieres una sola línea, aquí está compaudit | sed -n '2,$ p' | xargs -I{} chmod g-w {} - GMaster

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.

Respondido el 05 de diciembre de 20 a las 09:12

Esta fue la única solución que funcionó para mí en Mac Catalina: user8467470

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)

respondido 02 mar '21, 01:03

Esta debería ser la respuesta correcta. Al usar "sudo" debes tener cuidado. - Vaibhav Sidapara

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

Respondido 26 Oct 13, 02:10

esa fue la única solución que funcionó para mí. estaba tratando de usar zsh con compinit en el subsistema de Linux en Windows 10 - guaridas

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

Respondido 23 Feb 21, 17:02

Solo corriendo sudo chown $(whoami) PATH_HERE trabajó para mi. ¡Gracias! - R Sol

Esta respuesta fue la buena en mi caso. - Yohan W Dunon

Este fue el único que realmente funcionó para mí. Gracias - Mono del caos

Ú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

contestado el 11 de mayo de 20 a las 07:05

¡Esta es la única solución que me ayudó en macOS Catalina 10.15.5! Todas las otras cosas como compaudit | xargs chmod go-w or compinit -u no parece funcionar en esta versión de macOS - daniel l

La única solución que funcionó en macOS BigSur 11.2.1 (20D74). Muchas gracias. - Ahmet Ardal

La mejor solución hasta ahora. Dado que uso una cuenta separada en mi MacBook para varios clientes y uso personal, tengo varios usuarios que usan las carpetas zsh y no quiero cambiar de propietario todo el tiempo. Agregar esta variable de entorno eliminó al menos el mensaje molesto. - Joost den Boer

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

Respondido el 02 de diciembre de 16 a las 16:12

No tuve que hacerlo de esta manera en Sierra, aunque en un sistema multiusuario el usuario/grupo correcto debería ser root:staff - marshall eubanks

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

compaudit | xargs chmod g-w,o-w

contestado el 12 de mayo de 20 a las 21:05

teniendo solo este compaudit | xargs chmod gw funcionó para mí. - Jawadh Salih Rifath

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í

contestado el 19 de mayo de 20 a las 15:05

Esto funcionó perfectamente para mí en Big Sur: diek

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.

Respondido el 05 de junio de 20 a las 23:06

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:

Respondido 29 Abr '21, 09:04

no me ayudó - Koenig Lear

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"

Respondido el 22 de junio de 21 a las 05:06

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/*

Respondido el 16 de enero de 17 a las 11:01

¡Trabaja para mi! Uso una cuenta de red en mi PC - Ubutun 16.04 sudo chown -R $(whoami):root /usr/local/share/zsh sudo chown -R $(whoami):root /usr/local/share/zsh/* - hoangdv

... y si tiene enlaces simbólicos que apuntan a otro lugar, también debe eliminarlos: Sridhar Sarnobat

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"

Respondido el 14 de junio de 22 a las 16:06

Mejor aún: sudo chmod -R go-w /usr/local/share - ecmanaut

/usr/local/share/zsh es suficiente. - granvovan

Si usa terminaciones zsh: docs.brew.sh/Shell-Completion#configuring-completions-in-zsh dice a chmod -R go-w "$(brew --prefix)/share" - dijoncocina

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

Respondido 03 Abr '20, 13:04

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

Respondido 01 Feb 21, 20:02

también trabajó en MBP 1 que no es M2019 con OS 11.2 - david schumann

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

Respondido 26 Abr '17, 12:04

  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

Respondido el 15 de diciembre de 19 a las 06:12

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.

respondido 16 mar '20, 21:03

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.

respondido 19 mar '21, 16:03

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

Respondido el 11 de diciembre de 21 a las 15:12

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ó.

Respondido 15 Oct 19, 19:10

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"

respondido 23 nov., 20:10

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/

respondido 07 nov., 19:16

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

  • 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').

Respondido el 12 de diciembre de 20 a las 17:12

No es la respuesta que estás buscando? Examinar otras preguntas etiquetadas or haz tu propia pregunta.