¿Cómo configurar los permisos de Linux para la carpeta WWW?

69

Resumen actualizado

El directorio / var / www es propiedad de lo root:rootque significa que nadie puede usarlo y es completamente inútil. Como todos queremos un servidor web que realmente funcione (y nadie debería iniciar sesión como "root"), entonces debemos solucionarlo.

Solo dos entidades necesitan acceso.

  1. PHP / Perl / Ruby / Python necesitan acceso a las carpetas y archivos, ya que crean muchos de ellos (es decir /uploads/). Estos lenguajes de secuencias de comandos deberían ejecutarse bajo nginx o apache (o incluso alguna otra cosa como FastCGI para PHP).

  2. Los desarrolladores

¿Cómo obtienen acceso? Sé que alguien, en algún lugar, ha hecho esto antes. Sin embargo, con tantos miles de millones de sitios web por ahí, pensaría que habría más información sobre este tema.

Sé que 777 es un permiso completo de lectura / escritura / ejecución para el propietario / grupo / otro. Por lo tanto, esto no parece ser necesario, ya que otorga a los usuarios aleatorios permisos completos.

En qué permisos se deben usar /var/wwwpara que:

  1. Control de fuente como git o svn
  2. Usuarios en un grupo como "sitios web" ( o incluso agregados a "www-data" )
  3. Servidores como apache o lighthttpd
  4. Y PHP / Perl / Ruby

¿Pueden todos leer, crear y ejecutar archivos (y directorios) allí?

Si estoy en lo cierto, los scripts de Ruby y PHP no se "ejecutan" directamente, sino que se pasan a un intérprete. ¿Entonces no hay necesidad de ejecutar permisos en archivos en /var/www...? Por lo tanto, parece que el permiso correcto sería el chmod -R 1660que haría

  1. todos los archivos compartibles por estas cuatro entidades
  2. todos los archivos no son ejecutables por error
  3. bloquear a todos los demás del directorio por completo
  4. establecer el modo de permiso en "adhesivo" para todos los archivos futuros

¿Es esto correcto?

Actualización 1: Acabo de darme cuenta de que los archivos y directorios pueden necesitar diferentes permisos: estaba hablando de los archivos anteriores, así que no estoy seguro de cuáles deberían ser los permisos del directorio.

Actualización 2: la estructura de carpetas de los /var/wwwcambios drásticamente, ya que una de las cuatro entidades anteriores siempre agrega (y a veces elimina) carpetas y subcarpetas de muchos niveles de profundidad. También crean y eliminan archivos a los que las otras 3 entidades pueden necesitar acceso de lectura / escritura. Por lo tanto, los permisos deben hacer las cuatro cosas anteriores para archivos y directorios. Dado que ninguno de ellos debería necesitar permiso de ejecución (ver pregunta sobre ruby ​​/ php arriba) supongo que ese rw-rw-r--permiso sería todo lo que se necesita y completamente seguro ya que estas cuatro entidades son administradas por personal de confianza (ver # 2) y todos los demás usuarios en El sistema solo tiene acceso de lectura.

Actualización 3: Esto es para máquinas de desarrollo personal y servidores de empresas privadas. No hay "clientes web" aleatorios como un host compartido.

Actualización 4: Este artículo de slicehost parece ser el mejor para explicar lo que se necesita para configurar los permisos para su carpeta www. Sin embargo, no estoy seguro de qué usuario o grupo apache / nginx con PHP O svn / git se ejecutan y cómo cambiarlos.

Actualización 5: (creo) finalmente encontré una manera de hacer que todo funcione (respuesta a continuación). Sin embargo, no sé si esta es la forma correcta y SEGURA de hacerlo. Por lo tanto, he comenzado una recompensa. La persona que tiene el mejor método para asegurar y administrar el directorio www gana.

linux permissions chmod Xeoncross
fuente

Respuestas:

47

Después de más investigación, parece que otra (posiblemente una mejor manera) de responder esto sería configurar la carpeta www de esta manera.

  1. sudo usermod -a -G developer user1 (agregue cada usuario al grupo de desarrolladores)
  2. sudo chgrp -R developer /var/www/site.com/ para que los desarrolladores puedan trabajar allí
  3. sudo chmod -R 2774 /var/www/site.com/ para que solo los desarrolladores puedan crear / editar archivos (otro / mundo puede leer)
  4. sudo chgrp -R www-data /var/www/site.com/uploads para que www-data (apache / nginx) pueda crear cargas.

Dado que se gitejecuta como lo llame el usuario, entonces, siempre que el usuario esté en el grupo de "desarrolladores", deberían poder crear carpetas, editar archivos PHP y administrar el repositorio git.

Nota: En el paso (3): '2' en 2774 significa 'establecer ID de grupo' para el directorio. Esto hace que los nuevos archivos y subdirectorios creados dentro de él hereden la ID del grupo del directorio principal (en lugar del grupo primario del usuario) Referencia: http://en.wikipedia.org/wiki/Setuid#setuid_and_setgid_on_directories

Xeoncross
fuente
A mí me parece razonable.
wazoox
Bueno. Tal vez si puedo confirmar esto con un par de personas más, usaré este enfoque. Parece ser la mejor respuesta que he podido exprimir de la gente.
Xeoncross
No está especificando quién sería el propietario de los archivos. ¿Lo dejarías como root? Entonces solo los sudoers pueden editar su carpeta de cargas (probablemente no sea lo que pretendía).
Nic
Sí, root seguiría siendo el propietario. Sin embargo, dado que el propietario del grupo ahora es "desarrollador" (y tiene permiso wrx), todos los desarrolladores (y apache / nginx) también podrían leer. No hay necesidad de sudo.
Xeoncross
77
Una cosa más a tener en cuenta es umask. Muchos sistemas tienen una umask predeterminada de 022 que eliminará los permisos de escritura tanto para el grupo como para el público en los archivos nuevos. Sospecho que quieres 002 (sin escritura para público) o 007 (sin acceso para público). Puede configurar la umask en la configuración de Apache y / o las secuencias de comandos de inicio para cualquier proceso que necesite acceso al directorio. No olvide agregar esto a / etc / profile o / etc / bashrc para que también esté configurado por defecto para sus desarrolladores
Mark Porter
8

No estoy seguro de si es "correcto", pero esto es lo que hago en mi servidor:

  • / var / www contiene una carpeta para cada sitio web.
  • Cada sitio web tiene un propietario designado, que se establece como el propietario de todos los archivos y carpetas en el directorio del sitio web.
  • Todos los usuarios que mantienen el sitio web se colocan en un grupo para el sitio web.
  • Este grupo se configura como el propietario del grupo de todos los archivos y carpetas en el directorio.
  • Cualquier archivo o carpeta que deba ser escrito por el servidor web (es decir, PHP) tiene su propietario cambiado a www-data, el usuario con el que se ejecuta Apache.

Tenga en cuenta que debe tener habilitado el bit de ejecución en los directorios para poder enumerar los contenidos.

Nic
fuente
¿Cómo crea git / svn o PHP nuevas carpetas entonces?
Xeoncross
2
PHP se ejecuta en el mismo contexto de usuario que el servidor web, por lo que puede crear archivos y carpetas en cualquier directorio propiedad del servidor web. En general, solo hay unas pocas carpetas como esta (/ uploads / por ejemplo). No estoy seguro acerca de git / svn: ¿podría agregarlos a la cuenta de grupo que controla el sitio web?
Nic
aparentemente git se ejecuta como el usuario que lo ejecuta, como cualquier otra herramienta.
Xeoncross
Luego agregue el usuario git al grupo apache y otorgue permisos de escritura al grupo de carpetas.
David Rickman
Solo dije que git no tiene un usuario: se ejecuta como el usuario actual que lo usa.
Xeoncross
7

Después de investigar más, parece que git / svn TOOLS NO es un problema ya que se ejecutan como cualquier usuario que los esté usando. (Sin embargo, ¡los demonios git / svn son una cuestión diferente!) Todo lo que creé / cloné con git tenía mis permisos y la herramienta git se enumeró en /usr/binla tesis.

Permisos de Git resueltos.

Los permisos de usuario parecen resolverse agregando todos los usuarios que necesitan acceso al directorio www al www-datagrupo en el que apache (y nginx) se ejecutan.

Entonces parece que una respuesta a esta pregunta es así:

Por defecto /var/wwwes propiedad de root:rooty nadie puede agregar o cambiar archivos allí.

1) Cambiar propietario del grupo

Primero necesitamos cambiar el grupo de directorio www para que sea propiedad de "www-data" en lugar del grupo "root"

sudo chgrp -R www-data /var/www

2) Agregar usuarios a www-data

Luego necesitamos agregar el usuario actual (y cualquier otra persona) al grupo www-data

sudo usermod -a -G www-data demousername

3) directorio www CHMOD

Cambie los permisos para que SOLO el propietario (root) y todos los usuarios del grupo "www-data" puedan rwx (leer / escribir / ejecutar) archivos y directorios ( nadie más debería poder acceder a ellos ).

sudo chmod -R 2770 /var/www

Ahora todos los archivos y directorios creados por cualquier usuario que tenga acceso (es decir, en el grupo "www-data") serán legibles / grabables por apache y, por lo tanto, por php.

¿Es esto correcto? ¿Qué pasa con los archivos que PHP / Ruby crea? ¿Pueden los usuarios de www-data acceder a ellos?

Xeoncross
fuente
66
No me gusta la idea de que PHP pueda escribir todos los archivos web, esto aumenta su posible exposición si hay una vulnerabilidad de script.
Nic
Bien, sé que uso PHP para crear muchos archivos de texto, tar, log e imagen (más carpetas), así que estaba asumiendo que todo debería poder escribirse. Sin embargo, tal vez su derecho y PHP deberían poder CAMBIAR ARCHIVOS que CREA, lo que sería inofensivo ya que el 99% de todas las aplicaciones PHP nunca crean archivos de script. La otra opción parece ser permitir solo ciertos directorios con acceso de escritura PHP (/ uploads /), lo que no se hace desde entonces porque entonces PHP aún podría usarse para crear algo malo allí. ¿Algunas ideas?
Xeoncross
2
Intente mantener el script y los datos separados. Incluso si un atacante logra colocar algo en / uploads /, no debería ser ejecutable. La seguridad en capas es clave.
Nic
6

La adherencia no es herencia de permisos. La permanencia en un directorio significa que solo el propietario de un archivo, o el propietario del directorio, puede cambiar el nombre o eliminar ese archivo en el directorio, a pesar de que los permisos indiquen lo contrario. Así, 1777 en / tmp /.

En Unix clásico, no hay herencia de permisos basada en el sistema de archivos, solo en el umask del proceso actual. En * BSD, o Linux con setgid en el directorio, el campo de grupo de los archivos recién creados se establecerá de la misma manera que el directorio principal. Para algo más, debe buscar en las ACL, con la ACL 'predeterminada' en los directorios, que le permiten tener permisos heredados.

Debe comenzar definiendo: * qué usuarios tienen acceso al sistema * cuál es su modelo de amenaza

Por ejemplo, si está realizando alojamiento web con varios clientes y no desea que vean los archivos de los demás, entonces puede usar un grupo de "webcusts" para todos esos usuarios y un modo de directorio de 0705. Luego, los archivos servidos por el proceso del servidor web ( no en "webcusts") verá los Otros permisos y se permitirá; los clientes no pueden ver los archivos de los demás y los usuarios pueden meterse con sus propios archivos. Sin embargo, esto no significa que en el momento que permita CGI o PHP que tiene que asegurarse de que los procesos se ejecutan como el usuario específico (buenas prácticas de todos modos, para-varios usuarios-a-uno-anfitrión, para la rendición de cuentas). De lo contrario, los clientes podrían meterse con los archivos de los demás haciendo que un CGI lo haga.

Sin embargo, si el usuario en tiempo de ejecución de un sitio web es el mismo que el propietario del sitio web, entonces tiene problemas para no poder proteger el contenido de los abusadores en el caso de un agujero de seguridad en el script. Aquí es donde ganan los hosts dedicados, para que pueda tener un usuario en tiempo de ejecución distinto del propietario del contenido estático y no tener que preocuparse tanto por la interacción con otros usuarios.

Phil P
fuente
Buena respuesta. En MacOS X, el sistema se comporta como si el bit SGID estuviera en los directorios automáticamente. El bit adhesivo generalmente significa que solo puede eliminar el archivo si puede escribirlo. Es decir, cualquiera puede eliminar un archivo de escritura pública en / tmp. En MacOS X, / tmp es un enlace simbólico a un directorio privado para el usuario, por lo que no se puede compartir después de todo.
Jonathan Leffler
Gracias por la respuesta, he actualizado la pregunta con más información.
Xeoncross
Jonathan: el bit adhesivo significa que solo el propietario del directorio, o el propietario del archivo, puede cambiarle el nombre o eliminarlo (es decir, actuar sobre su entrada en el directorio 'archivo'). Los permisos en el archivo individual no entran en juego para estas operaciones de directorio ( rename(), unlink()), solo para acciones en el archivo en sí ( open()). Este es el comportamiento "habitual".
Phil P
2

Creo que la mejor manera de hacerlo es utilizando las ACL de Posix. Son cómodos para trabajar y ofrecen toda la funcionalidad que necesita.

http://en.wikipedia.org/wiki/Access_control_list#Filesystem_ACLs

Luchador de corbata
fuente
+1 para obtener información útil sobre ACL. Sin embargo, no quiero basura adicional que empañe el sistema solo para administrar un servidor simple con un par de desarrolladores. Tampoco me siento cómodo compilando el Kernel para usar ACL.
Xeoncross
@ Xeoncross: las ACL no empantanan nada. Son solo metainformación como los permisos de archivo normales. No es tan "extra" y complicado, creo que es la mejor y más simple forma de administrar los permisos en lugar de una solución confusa de "grupo" / "lo que sea". ¡No tengas miedo, solo vuelve a montar con acl y pruébalo!
Tie-fighter
1

El propietario del archivo debe ser la persona que lo crea, mientras que el grupo debe ser www-data. El modo para directorios / archivos es en general 755/644. Mientras que para directorios y archivos el grupo necesita acceso de escritura, el mod es 775/664. Supongamos que Paddy es el desarrollador. En total esto hace:

chown -R paddy:www-data /var/www/websiteindevelopment
chmod -R 755 /var/www/websiteindevelopment
chmod -R 775 /var/www/websiteindevelopment/directorywritablebygroup
find /var/www/websiteindevelopment -type f -perm 755 -print -exec chmod 644 {} \;  
find /var/www/websiteindevelopment -type f -perm 775 -print -exec chmod 664 {} \;
Jonny
fuente
0

Agregando a la respuesta de @ Xeoncross, creo que sería bueno configurar los permisos en archivos y directorios por separado. 

sudo find /var/www -type d -exec chmod 775 {} \;  # Change permissions of directories to rwxrwxr-x
sudo find /var/www -type f -exec chmod 664 {} \;  # Change file permissions to rw-rw-r--

Esto permitirá a los desarrolladores crear y modificar directorios dentro de / var / www. Lo que parece importante porque los desarrolladores pueden necesitar crear directorios adicionales o eliminar un directorio que ya no es necesario.

También permitirá a los desarrolladores crear y modificar archivos de código (leer archivos HTML, PHP y similares). Pero, solo permitirá el acceso de solo lectura para todos los demás.

MikeyE
fuente