zsh compinit: directorios inseguros


238

¿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]?

Al ejecutar el compauditdevuelve lo siguiente:

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

2
Alguien sabe por qué ocurre esta advertencia?
Blaszard

3
Un año después de que @Blaszard hiciera la pregunta válida (como comentario), 'linkyndy' la respondió a continuación (como respuesta).
Happy Green Kid Naps

Respuestas:


343

Esto me lo arregló:

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

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


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

$ sudo chown -R root:root ./site-functions

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

EDIT2: en OSX 10.11, solo esto funcionó:

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

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


1
¿y si usted no tiene ninguna raíz
kirill_igum

2
@kirill_igum por "sin root" ¿quiso decir "sin acceso root "? Si es así, debe copiar los archivos a una carpeta a la que tenga acceso, arreglar su .zshenvy .zshrcusar la nueva carpeta y hacer lo mismo chmoden la nueva carpeta que publiqué con la carpeta.
chakrit

@kirill_igum ver el mensaje de la lista de correo que he vinculado.
chakrit

1
Me di cuenta de que después de configurar el propietario como root, el acceso de escritura debía ser revocado tanto para el grupo como para otros. Modifiqué el chmodcomando a sudo chmod -R go-w zsh.
gdvd

1
Nota: tuve enlaces simbólicos en los /usr/local/share/zsh/site-functionsque /usr/local/Cellare tenido que chown -R root:staff /usr/local/Cellartambién antes de esto funcionó.
mVChr

268
compaudit | xargs chmod g-w

hará el truco, consulte http://www.wezm.net/technical/2008/09/zsh-cygwin-and-insecure-directories/


66
¡Eso es todo! Eliminando el permiso de escritura para agrupar. Gracias
glarrain

8
Mucho mejor respuesta, debe tenerse en cuenta que compauditse puede utilizar para diagnosticar problemas como estos y solucionarlos.
Wolph

8
Tenga en cuenta que también puede tener que cambiar el propietario de los archivos a la raíz, así - que tenía que:compaudit | xargs chown root
Brad Parks

44
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 sea propiedad de root.
Katy Lavallee

2
compaudit | xargs chmod g-wjunto con ompaudit | xargs chown roottrabajó para mí también y parecía mantener contento a HomeBrew. ¿Alguien puede explicar qué está pasando un poco más?
nyxee

76

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

Por razones de seguridad, compinit también verifica si el sistema de finalización usaría archivos que no sean propiedad de root o del usuario actual , o archivos en directorios que se puedan escribir en todo el mundo o en grupo o que no sean propiedad de root o del usuario actual . Si se encuentran dichos archivos o directorios, compinit le preguntará si realmente debe usarse 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 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:

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

    compaudit | xargs chown -R "$(whoami)"
    
  • eliminando permisos de escritura para grupo / otros para los archivos en la causa:

    compaudit | xargs chmod go-w
    

Otro enfoque sería omitir estas comprobaciones utilizando

compinit -u

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


1
Gracias. Me sorprende que la gente escriba comandos al azar sin comprender realmente el problema.
chilla el

3
¿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. Según los documentos, ¿no tendría más sentido hacer que los archivos sean propiedad de root?
goetzc

Me gusta esta respuesta la mejor. Me hizo pensar por qué me pasó esto. 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

25

Recibí las mismas advertencias cuando comencé sudo -iun shell raíz, la solución de @ chakrit no funcionó para mí.

Pero encontré el -ucambio de compinitobras, por ejemplo, en su .zshrc / zshenv o donde llamócompinit

compinit -u

NB: no recomendado para el sistema de producción

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


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
denns

17

Esto funciona para mi Mac después de actualizar a High Sierra.

Eliminar el acceso de escritura grupal:

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.


1
sudo chmod gw / usr / local / share / zsh / site-functions (funcionó para mí en mac 10.15)
shijin

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

1
Esta solución también me funcionó en MacOS Catalina. ¡Gracias!
Tyler hace

12

La respuesta aceptada no funcionó para mí en macOs Sierra (10.12.1). Tuve que hacerlo de forma recursiva desde / usr / local

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

Nota: puede obtener su nombre de usuario whoamiy su grupo conid -g


44
No tenía que hacerlo de esta manera también en Sierra, aunque en un sistema multiusuario el usuario / grupo correcto debería ser root: personal
Marshall Eubanks

5

Estas dos líneas me han arreglado.

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

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

3
¡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

5

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


4

Lo arreglé haciendo

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

en mi caso, otros directorios dentro de compartir / también tienen asignado un grupo de "personal"


La pregunta no es sobre el tema de Stack Overflow como se define en el centro de ayuda . Por favor no conteste tales preguntas; en su lugar, debe marcarlos para llamar la atención y se cerrarán o migrarán adecuadamente.
Toby Speight

4

en Mojave, esto hizo el truco: sudo chmod go-w /usr/local/share


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

3

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



3

Mi maquina:

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

Así que aquí está lo que hice.

  1. ejecutar compaudity le dará una lista de directorios que considera inseguros.

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

Ejemplo:

compaudit

devoluciones:

/ usr / local / share / zsh

entonces corro

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

leer más aquí enlace


2

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, así:

# 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 nuevamente rooty el problema desapareció. Yo no necesito cambiar los permisos, y no sería recomendable el hacerlo a no ser que se entiende la causa subyacente del problema.

sudo chown root _code && sudo chgrp root _code

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


2
  1. ejecutar compaudity le dará una lista de directorios que considera inseguros

  2. sudo chown -R username:root target_directory

  3. sudo chmod -R 755 target_directory


2

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

ZSH_DISABLE_COMPFIX=true


1

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

compaudit | xargs chmod g-w,o-w


1

Solución MAC OS X:

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

También "user: staff = usuario root predeterminado en OSX.


Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.