¿Son correctos mis permisos para /usr/local/?

Estoy usando HomeBrew para mis necesidades de puerto (parece un poco "más limpio" que MacPorts).

Puedo instalar sin sudoing (lo cual es genial), pero el paso de vinculación del hombre parece requerirlo ( /usr/local/share/man/man3es propiedad de root).
Una guía que encontré sugiere que recursivamente chown /usr/localhaciendo

sudo chown -R `whoami` /usr/local

¿Es esto seguro… o es una Mala Idea™?

También: ¿mis permisos son correctos?

$ pwd
/usr/local/share/man
$ ls -lah
total 32
drwxrwxr-x    8 root  staff   272B  4 Set 11:02 .
drwxrwxr-x    9 root  staff   306B 10 Set 11:27 ..
drwxr-xr-x    3 root  wheel   102B  4 Ago  2009 de
drwxrwxr-x  163 root  staff   5,4K 10 Set 11:27 man1
drwxr-xr-x   11 root  wheel   374B 10 Set 11:27 man3
drwxr-xr-x    7 ago   staff   238B 10 Set 11:39 man5
drwxr-xr-x   11 ago   staff   374B 10 Set 11:39 man7
-rw-r--r--    1 root  staff    13K  4 Set 11:02 whatis
Así es como se debe usar Homebrew. Algunas personas pueden no estar de acuerdo, pero el desarrollador principal dice que se hagan las cosas de esa manera.
Una alternativa ligeramente mejor a tu chown: sudo chown -R :admin /usr/local. De esta forma, funcionará igual para cualquier usuario administrador de la máquina. Aunque es posible que también deba ejecutar sudo find /usr/local -perm -200 -exec chmod g+w '{}' \+para asegurarse de que el grupo tenga el mismo acceso de escritura que el usuario.
"Usaré homebrew, se siente más limpio que macports. Oh, mira este lío de permisos mal definidos. Revisaré Stack Overflow. Oh, aquí hay un truco rápido que va en contra de las mejores prácticas de Unix y en contra de lo que intentan las actualizaciones del sistema operativo para hacer cumplir. ¡Perfecto!". Mes después: "Oye, ¿cómo se instaló este malware?"
El problema que tengo con este enfoque es que significa que solo la cuenta de usuario que instala Homebrew puede usarlo. Tengo una Mac con varias cuentas que uso para mantener los proyectos de trabajo separados de los proyectos domésticos (por ejemplo). Si he iniciado sesión en la cuenta incorrecta, no puedo usar brew install. He tomado esta ruta para evitar los peligros de usar root, pero no estoy convencido de que sea el mejor enfoque.
@MikeMcQuaid Me parece interesante que Homebrew finalmente haya admitido la falla en esto y en la nueva versión lanzada hace una semana o dos, haya restaurado los permisos predeterminados para /usr/local
@Agos Ver comentario arriba

Respuestas (7)

Por lo general, es mejor mantener los permisos lo más estrictos posible. Mantener /usr/localpropiedad rootsignifica que solo los procesos que se ejecutan como root/ sudo(o solicitan un usuario administrador a través del cuadro de diálogo de autorización de Apple) pueden escribir en esta área. Por lo tanto, una descarga de proceso debe solicitarle una contraseña antes de corromper los archivos allí.

Pero como dices, hace que agregar nuevos programas sea más difícil.

Estoy de acuerdo con ejecutar sudo, ya que instala cosas con menos frecuencia que ejecutarlas, pero debe confiar en que el proceso de compilación no cambia nada de lo que debería.

Si desea evitar sudo, instalaría Homebrew ~/usr/localy modificaría su ruta, manpath, etc. para incluir los directorios que se encuentran debajo.

Una mejor manera es crear otro usuario, digamos, homebrewy crear un directorio propiedad de ese usuario. Luego, instálelo allí usando sudo -U homebrew. Otros usuarios tendrán la ventaja de no poder sobrescribir ningún otro archivo, porque no se están ejecutando rooty otros programas no pueden afectar a homebrew. (Observo que las preguntas frecuentes de Homebrew sugieren este nuevo usuario si se encuentra en un "entorno multiusuario". Diría que cualquier máquina Unix, incluido macOS, es un entorno multiusuario)

Sin embargo, como dice el wiki de Homebrew, las recetas no encuentran todos los casos /usr/localy los reemplazan con el directorio elegido con el que sospecho que estamos atascados /usr/local.

+1 por mantener estrictas las autorizaciones y alterar $PATHe $MANPATHincluir directorios de usuarios. Si los programas instalados no requieren una instalación en todo el sistema, es una alternativa mucho mejor.
+1 y respuesta aceptada para "mantener los permisos lo más estrictos posible". Hacer brew doctor(sugerido a continuación) me dijo que solo tengo que elegir los directorios de hombres compartidos... lo suficientemente seguro para mí.
Una solución de compromiso, al menos para las personas que se preocupan por la seguridad lo suficiente como para no ejecutarse como usuarios administradores todo el tiempo, es cambiar la propiedad y los permisos del grupo para que solo los administradores puedan escribir en /usr/local. Ver la respuesta de kenorb.
@Mark Me parece interesante que Homebrew finalmente haya admitido la falla en esto y en la nueva versión lanzada hace una semana o dos, haya restaurado los permisos predeterminados para /usr/local

También uso Homebrew y puedo confirmar que es totalmente seguro. Citando la página de instalación en las preguntas frecuentes oficiales de Homebrew :

Hazte un favor y elige/usr/local

  1. Es más fácil
    /usr/local/bin ya está en tu PATH.

  2. Es más fácil
    que se rompan toneladas de scripts de compilación si sus dependencias no están en /usr o /usr/local. Arreglamos esto para las fórmulas de Homebrew (aunque no siempre lo probamos), pero encontrará que muchos scripts de configuración de RubyGems y Python se rompen, lo cual es algo que está fuera de nuestro control.

  3. Es seguro que
    Apple se ha conformado con POSIX y nos ha dejado este directorio. Lo que significa que no hay un /usr/localdirectorio predeterminado, por lo que no hay necesidad de preocuparse por estropear las herramientas existentes.

Si planea instalar gemas que dependen de las cervezas, ahórrese un montón de problemas e instálelo en /usr/local!

No es trivial decirle a gem que busque encabezados y dylibs en directorios no estándar. Si elige /usr/local, ¡todo “simplemente funciona!”

Solo agregaré que hacer las cosas como root es una muy mala idea , por lo que chowning /usr/localno solo me parece razonable (no es un directorio de sistema en OSX), sino cuerdo .

Sus permisos no son correctos (todavía). Simplemente ejecute el comando que enumeró y estará bien.

Si tienes otros problemas recuerda, ¡los brew doctorpueden ayudarte!

Los comentarios no son para una discusión extensa; esta conversación se ha movido a chat .
El chat se ha ido, lo cual es una pena. Entonces, a riesgo de repetir la historia, dejaré aquí mi comentario: que esto se haga no significa que sea seguro.
La esencia del gráfico es que, aunque esto es lo que Homebrew sugiere, hay razones por las que esto está mal.
brew doctores simplemente impresionante.
@Carmine Paolino Me parece interesante que Homebrew finalmente haya admitido la falla en esto y en la nueva versión lanzada hace una semana o dos, haya restaurado los permisos predeterminados para /usr/local

Si está utilizando Homebrew, debe otorgar el permiso de escritura a un grupo específico (ya sea admino staff), para que los archivos puedan compartirse entre los usuarios que están en ese grupo.

Por ejemplo:

sudo chgrp -R admin /usr/local /Library/Caches/Homebrew
sudo chmod -R g+w /usr/local /Library/Caches/Homebrew

Luego asigne los usuarios que deberían tener acceso al brewcomando a ese grupo (consulte sus grupos a través de: id -Gn).

Luego, cuando trabaje con brew, no lo ejecute con sudo.

Cuando aún tenga algún problema de permiso, ejecute brew doctorpara solucionar el problema.

+1 por brindar una solución real y de mejor comportamiento, incluso si no está realmente terminada. Por ejemplo: ¿agregar un usuario al grupo de administración en el nivel BSD? ¿Eso no afectará el concepto de usuarios administradores de OS X?
Para que conste, seguí estas instrucciones, pero solo usé mi usuario administrador creado por la GUI de OS X existente en lugar de agregar a alguien a cualquier grupo en la CLI. Funciona: para poder ejecutar los comandos de preparación, primero tengo que hacer su myAdminUsery luego todo funciona según lo previsto. Pero, por supuesto, esta solución no brindará ninguna seguridad a las personas que, de todos modos, ya están ejecutando un usuario administrador todo el tiempo.
Esta es probablemente la mejor manera de hacerlo, estoy de acuerdo con @kenorb

Por lo que vale, /usr/localno se considera una carpeta de "sistema" por OS X, y en una nueva instalación de Snow Leopard, esa carpeta está vacía.

Cualquier cosa que sea propiedad de la raíz en esa carpeta es el resultado de sudo make installotro software, o de dar su contraseña después de hacer doble clic en un archivo .pkgque quiere volcar cosas en un archivo /usr/local.

Ser propietario /usr/localha "funcionado para mí" en 2 máquinas durante más de un año.

Un problema es que si instaló MySQL (sin usar Homebrew) y cortó sus archivos, entonces probablemente ya no podrá ver sus bases de datos (por lo que tendría que volver a choncharlos a cualquier usuario que MySQL esté ejecutando como .)

gcc y otras herramientas de desarrollo buscan automáticamente en /usr/local, por lo que afecta el sistema
El problema no es que sea una carpeta de "sistema"; es que es una carpeta de "todo el sistema". Incluso si no hay nada allí, /usr/local/bintodavía está en el valor predeterminado $PATH, y cualquier cosa que coloque allí también puede ser utilizada por otros usuarios y debe ser de confianza . Si todo el /usr/local/directorio tiene los mismos permisos /usr/local/share/manque tiene actualmente en la configuración de OP, cualquiera puede ir y cambiar cualquier binario con un script que lo haga rm -rf ~.
demasiado arriesgado: es probable que instale MySQL tarde o temprano
@Agos: siempre puedes instalar MySQL con HomeBrew, en cuyo caso no tendrás ningún problema :)
@CarminePaolino No es una gran idea. Por lo general, los instaladores de Mac, como MySql, se comportan mejor que incluso un muy buen administrador de paquetes como Homebrew.
@Agos No es nada arriesgado. La precaución solo se aplica si ha instalado MySQL antes que Homebrew. Si lo hace después, los permisos /usr/localdeberían estar bien. (Pero probablemente uses Postgres de todos modos. :))

Como en Homebrew 1.0.0:

Homebrew ya no necesita tener la propiedad de /usr/local. Si lo desea, puede devolver /usr/local a su propiedad predeterminada con: sudo chown root:wheel /usr/local

Actualmente estoy actualizando Brew usando brew update, que aún requiere la propiedad de /usr/local. Intentaré restaurar los permisos después.
¡Esta es realmente una gran información! Configuré los permisos según lo especificado por Homebrew (<1.0), y después de la actualización, me dio estas instrucciones sobre cómo restablecerlos.

A partir de macOS High Sierra o posterior, /usr/localya no se puede chown.

El equipo de Homebrew ahora recomienda : sudo chown -R $(whoami) $(brew --prefix)/*corregir los permisos de Homebrew.

Consulte la respuesta de @Carmine Paolino para obtener más información sobre por qué Homebrew recomienda tomar posesión de los directorios de Homebrew.

Creo que está bien que los usuarios tengan permisos de escritura /usr/local; después de todo, eso significa que no está usando sudoen cada script de compilación. No me gusta la idea de que un usuario ordinario posea /usr/local . Preferiría tener root (o similar) /usr/local, pero cambiar los permisos para que los usuarios (o al menos algún grupo privilegiado) puedan escribir en él. Ese parece ser el enfoque conceptualmente correcto.

El problema aquí es que /usr/local/binpuede muy bien estar al frente de $PATH para la mayoría de los usuarios. Hacer que el directorio sea escribible por todo el mundo abre muchos agujeros de seguridad de esa manera.
@patrix Así que cambia los caminos. :) Si tiene secuencias de comandos que tienen agujeros de seguridad debido a rutas de comando ambiguas, culparía a las secuencias de comandos, no a sus permisos: los comandos invocados en las secuencias de comandos generalmente deberían estar completamente calificados exactamente por este motivo. De todos modos, no hay mejor solución: o le da a su cuenta de administrador un umask inseguro, o ejecuta todos sus scripts de compilación con sudo, o le da a algunos usuarios permisos de escritura para /usr/local. Tomaré el tercero como el menos riesgoso... a menos que conozca una mejor manera.
Mmm. Pensando en esto un poco más, tal vez una mejor manera sería hacer que Homebrew haga lo que RVM hace por defecto: instalar todo en ~/brewo algo así. Sin embargo, el problema es que, a diferencia de Ruby, que es bastante autónomo, muchas utilidades *nix esperan encontrarse en /usr/local...
Olvidé mencionar que /usr/localno se puede escribir en todo el mundo: más bien, tengo un grupo de confianza homebrew(no solo administrador) que tiene permisos de escritura (permisos extendidos como 0: group:homebrew allow add_file,delete,add_subdirectory,delete_child,file_inherit,directory_inherittotalmente rock). Este es el mejor compromiso que he podido encontrar: no sudoen los scripts de compilación, pero sí algo de control sobre /usr/local.
@MarnenLaibow-Koser Me encantaría ver una explicación más detallada de este enfoque (crear un grupo confiable de usuarios con permisos de escritura para /usr/local). Navegando mucho en SO y otros sitios, viendo argumentos sobre: ​​mover Homebrew a la carpeta de inicio del usuario versus mantenerlo /usr/local, cambiar de propietario y/o grupo /usr/localo no, y así sucesivamente... es difícil saber si hay alguna solución universalmente aceptable. ¿Tiene una publicación de blog o un artículo sobre esto, o podría dar una explicación más profunda en alguna parte?
@GabrielL. se reduce a si tiene más de un usuario (y también mi respuesta) si es así, ¿cuál usuario debería poseer /usr/local?
@GabrielL. ¿Qué parte no entiendes? Si comprende cómo funcionan los permisos *nix y piensa en quién debería poder escribir /usr/local, la configuración debería ser evidente.
@MarnenLaibow-Koser: gracias por la respuesta. No es que no lo entienda, sino que no sé lo que no sé. ;-) Principalmente, estaba tratando de discernir cuáles podrían ser las posibles desventajas / desventajas de ese enfoque. Parece un buen compromiso.
@GabrielL. Homebrew sugiere de esta manera en sus preguntas frecuentes, pero para un "entorno de múltiples usuarios"
@Marnen: debemos tener en cuenta que, dado que Catalina /usr/local es un enlace firme, no puede crear una ACL para él. Por lo tanto, debe hacerlo para los subdirectorios. Lo acabo de probar y funciona: /usr/local/bin es root:wheel, pero la ACL para el grupo _brew permite el acceso. Sin embargo, su propia cuenta también debe ser miembro de ese grupo. Y luego, cada proceso que se ejecute como su usuario aún podrá escribir en esos subdirectorios, sin privilegios de root. Necesitamos una manera de hacer que funcione sin agregar su propio usuario a ese grupo. ¿Hay alguna manera de cambiar su usuario a un grupo al que no pertenece?
No... responda a la última pregunta: si agrega su usuario al grupo _brew, seguirá estando en el personal (20). Entonces brew doctorle dirá que /usr/local/bin no se puede escribir. Si cambia al grupo _brew con newgrp brew, entonces brew doctorno marcará /usr/local/bin. Así que esta es en realidad una solución bastante decente.
PD: no, parece que solo funcionó en la sesión de Terminall original. Después de un nuevo inicio de sesión, se acepta el grupo _brew, 501 y _brew están "casados", y no es necesario cambiar de grupo para escribir en /usr/local/bin... por lo que no hay seguridad adicional con este enfoque. Entonces, la pregunta original sigue en pie: ¿hay alguna forma de cambiar a un usuario a un grupo del que no es miembro?
@JayB Puede agregar un usuario a cualquier grupo que desee.
¿Son correctos mis permisos para /usr/local/?
RespuestasAquíPolítica de privacidad1y, 0v