Pregunta ¿Cuál es la mejor manera de manejar los permisos para los usuarios de Apache 2 www-data en / var / www?


¿Alguien tiene una buena solución para manejar archivos en /var/www? Estamos ejecutando hosts virtuales basados ​​en nombre y el usuario de Apache 2 es www-data.

Tenemos dos usuarios regulares y root. Así que cuando se mete con archivos en /var/www, en lugar de tener que ...

chown -R www-data:www-data

... todo el tiempo, ¿cuál es una buena manera de manejar esto?

Pregunta complementaria: ¿Qué tan duro vas a los permisos?

Éste siempre ha sido un problema en entornos de desarrollo colaborativo.


211
2018-05-11 05:13


origen


Ver también: ¿Cuáles son los mejores permisos de Linux para usar en mi sitio web? - Zoredache


Respuestas:


Intentando expandir en @ Zoredache's responder, como le doy una oportunidad a mi mismo

  • Cree un nuevo grupo (www-pub) y agregue los usuarios a ese grupo

    groupadd www-pub

    usermod -a -G www-pub usera  ## debe usar -a para adjuntar a grupos existentes

    usermod -a -G www-pub userb

    groups usera  ## muestra grupos para el usuario

  • Cambie la propiedad de todo bajo / var / www a root: www-pub

    chown -R root:www-pub /var/www  ## -R para recursivo

  • Cambia los permisos de todas las carpetas a 2775.

    chmod 2775 /var/www  ## 2 = establecer ID de grupo, 7 = rwx para el propietario (raíz), 7 = rwx para el grupo (www-pub), 5 = rx para el mundo (incluido el usuario de datos www de apache)

    Establecer ID de grupo (SETGID) el bit (2) hace que el grupo (www-pub) se copie a todos los nuevos archivos / carpetas creados en esa carpeta. Otras opciones son SETUID (4) para copiar el ID de usuario, y STICKY (1) que creo que solo permite al propietario eliminar archivos.

    Hay una -R opción recursiva, pero eso no discriminará entre archivos y carpetas, por lo que tiene que usar encontrar, al igual que:

    find /var/www -type d -exec chmod 2775 {} +

  • Cambia todos los archivos a 0664.

    find /var/www -type f -exec chmod 0664 {} +

  • Cambia el umask para tus usuarios a 0002

    Umask controla los permisos de creación de archivos predeterminados, 0002 significa que los archivos tendrán 664 y directorios 775. Al establecer esto (editando el umask línea en la parte inferior de /etc/profile en mi caso) significa que los archivos creados por un usuario serán editables por otros usuarios en el grupo www sin necesidad de chmod ellos.

Pruebe todo esto creando un archivo y un directorio y verificando el propietario, el grupo y los permisos con ls -l.

Nota: ¡Deberá iniciar sesión / iniciar sesión para que los cambios en sus grupos surtan efecto!


201
2017-09-15 05:11



@Tom genial ver que recomiendas usar el findcomando para esto Un pequeño consejo de rendimiento que daría si tuviera muchos archivos / directorios y estuviera usando GNU find es usar + en lugar de \; para que la orden sea operar en múltiples archivos porque "es más rápido ejecutar un comando en tantos archivos como sea posible a la vez, en lugar de una vez por archivo. Al hacerlo, se ahorra el tiempo que toma iniciar el comando cada vez". Además, es más fácil de escribir ya que no necesita barra invertida. - aculich
Actualizado con la sugerencia de @ aculich de usar + not \; - Tom
@SunnyJ. intente esto (sin las comillas externas): "encuentre / var / www -type f -exec chmod 0664 '{}' \ +" Inténtelo. Hay un espacio entre el '{}' y el \ +. - Buttle Butkus
@ Tom- manera de descomponerlo, gracias. Solo una nota. Creo que "SETUID (4) para copiar la ID de usuario" como se incluye en su respuesta es incorrecta. SETUID se ignora cuando se aplica a directorios en Linux / Unix - Árbitro - Yarin
Ok asi que por usera y userb Quieres decir www-data y ftpuser ? Esto me pareció muy confuso con cualquier mención de www-data, que estaba en la pregunta original. Además, ¿cuál es el punto / beneficio de configurar el propietario para root? ¿Deberíamos ponerlo a ftpuser? - gskema


No estoy completamente seguro de cómo desea configurar los permisos, pero esto puede darle un punto de partida. Probablemente hay mejores maneras. Supongo que desea que ambos usuarios puedan cambiar cualquier cosa en / var / www /

  • Cree un nuevo grupo (www-pub) y agregue los usuarios a ese grupo.
  • Cambie la propiedad de todo bajo / var / www a root: www-pub.
  • Cambia los permisos de todas las carpetas a 2775.
  • Cambia todos los archivos a 0664.
  • Cambia el umask para tus usuarios a 0002

Esto significa que cualquier archivo nuevo creado por cualquiera de sus usuarios debe ser nombre de usuario: www-pub 0664 y cualquier directorio que se cree será nombre de usuario: www-pub 2775. Apache obtendrá acceso de lectura a todo a través del componente "otros usuarios". El bit SETGID en los directorios obligará a que todos los archivos que se crean sean propiedad del grupo que posee la carpeta. Es necesario ajustar la umask para asegurarse de que el bit de escritura esté establecido para que cualquier persona del grupo pueda editar los archivos.

En cuanto a lo incondicional voy en los permisos. Depende completamente del sitio / servidor. Si solo hay 1 o 2 editores y solo necesito evitar que rompan las cosas demasiado mal, entonces iré fácil. Si el negocio requiriera algo más complejo, entonces configuraría algo más complejo.


59
2018-05-11 05:49



Posible adición: configure los directorios de caché / carga que el servidor web debe escribir en www-data: www-data y 775. - gacrux
¿Sería tan bueno agregar los usuarios al grupo de apache en lugar de confiar en 'otros' permisos? Si todo lo que está haciendo es cargar archivos y esos archivos deben ser legibles por apache, un tercer grupo solo parece ser útil si necesita editar esos archivos. - Simurr
¿Alguna posibilidad de que puedas expandir esto un poco @Zoredache? Reitero el uso básico de bits rwx, chmod, chown, adduser, usermod, pero me perdiste con el primer dígito adicional en los permisos octales, umasks y todo eso. Algunos comandos de muestra que ilustran su enfoque descrito serían muy apreciados. - Tom
De esta manera, todos los usuarios pueden acceder a los archivos de otros usuarios! Esto significa que el usuario A puede leer config.php del usuario B ... robando su credencial mysql, por ejemplo - drAlberT
Usando acl puedes manejar tanto la seguridad como la colaboración :) - drAlberT


Creo que puede ser útil POSIX ACL (listas de control de acceso). Permiten un modelo de permiso más preciso en comparación con el usuario: grupo: otro modelo. He encontrado que son más fáciles de mantener en mi cabeza ya que puedo ser más explícito y también puedo establecer el comportamiento "predeterminado" para una rama del sistema de archivos.

Por ejemplo, puede especificar explícitamente los permisos de cada usuario:

setfacl -Rm d:u:userA:rwX,u:userA:rwX /var/www
setfacl -Rm d:u:userB:rwX,u:userB:rwX /var/www

O puedes hacerlo en base a algún grupo compartido:

setfacl -Rm d:g:groupA:rwX,u:groupA:rwX /var/www

Y tal vez desee mantener a su usuario de Apache como de solo lectura

setfacl -Rm d:u:www-data:rX,u:www-data:rX /var/www

Páginas de manual:

Tutorial


39
2018-05-11 16:26



Eso es la manera ! +1 - drAlberT
ACL para la victoria +1 ... Para más información serverfault.com/a/360120/41823 - Yarin
Me pregunto si hay algún inconveniente de rendimiento para los permisos ACL vs básicos. - Buttle Butkus
Desafortunadamente, ACL falta a menudo en instalaciones / distribuciones estándar. Es un dolor compilar el kernel en todos los servidores que gestiono, o peor, cambiar el sistema de archivos a veces. Además, debe tener mucho cuidado al hacer copias de seguridad de los archivos, especialmente si está cambiando de servidor. ACL es excelente, pero su soporte actual es tan bajo que lo recomendaría a cualquiera que no tenga control total sobre todo el servidor y los alrededores. ¡Pero +1 por señalar ACL donde realmente tiene sentido! - Ninj
Buena respuesta +1; Una nota sobre cómo cambiar los permisos de lectura / escritura del proceso de apache (www-data por ejemplo) a solo lectura para todo el sitio (a través de setfacl o chmod, o ambos) -> Esto obviamente bloqueará todas las escrituras (carga / actualización de plugin / módulo desde el navegador en la mayoría de los CMS, por ejemplo). Creo que muchos populares también solo prueban el acceso de escritura en el nivel de permiso del usuario, no el nivel de grupo. Aún puede actualizar, pero las actualizaciones deben aplicarse manualmente y todos los permisos personalizados para las carpetas de escritura (logs / temp / uploads / etc). Solo lectura es una gran seguridad si su sitio funciona con él. En general, la mayoría no lo hace. - bshea


Esta pregunta fue preguntó de nuevo, y como discutido en meta, las mejores prácticas actuales ofrecen mejores enfoques de los que estaban disponibles en 2009, cuando se solicitó esto. Esta respuesta trata de dar algunas soluciones actuales para Manejo seguro de entornos de desarrollo web colaborativo..


Para un servidor web seguro y un desarrollo colaborativo, hay más que solo permisos de archivos:

  • Tener usuario separado para cada sitio es decir, no sirven todos los sitios usando www-data. Esto es importante, ya que hoy en día Apache rara vez sirve únicamente estático archivos de contenido, pero en ejecución dinámica sitios web Esta respuesta se concentra en PHP ya que es la más común Idioma del sitio del servidor, pero los mismos principios se aplican a los demás, también.

    Si tiene un problema de seguridad en un solo sitio, puede propagarse a todos los sitios que se ejecutan como el mismo usuario. Un atacante puede ver todo lo que ve el usuario, incluida la información de inicio de sesión en la base de datos, y modificar todos los sitios en los que el usuario tiene permisos de escritura.

  • Utilizar Protocolo de transferencia de archivos SSH (SFTP). Si bien el uso de FTP debe abandonarse por seguridad (ya que envía tanto las contraseñas como el contenido en texto sin formato), su sustituto seguro SFTP también tiene una característica que es una solución perfecta para el desarrollo web colaborativo.

    Una vez que haya aislado los sitios y un usuario por sitio, debe dar acceso a sus desarrolladores web, de lo que se trata esta pregunta. En lugar de darles las contraseñas para estos usuarios del sitio, o acceder a los archivos del sitio usando sus cuentas de usuario personales como se sugirió originalmente, puede usar Llaves SSH para iniciar sesión

    Cada desarrollador puede generar par de llaves y mantener la clave privada en secreto. Luego, la clave pública se agrega a la ~/.ssh/authorized_keys archivo para cada cuenta de usuario del sitio web en el que el desarrollador está trabajando. Esto tiene muchas ventajas para administrar las contraseñas y los inicios de sesión:

    • Cada desarrollador puede tener acceso a cualquier número de sitios web sin la carga de recordar o almacenar todas las contraseñas involucradas con el acuerdo de usuario por sitio.

    • No es necesario cambiar y compartir las contraseñas cada vez que alguien abandona la empresa.

    • Puede usar contraseñas muy seguras o deshabilitar el inicio de sesión basado en contraseña por completo.

  • Usa PHP-FPM. Es el enfoque actual para ejecutar PHP como usuario. Crear un nuevo piscina para cada usuario, es decir, un grupo por cada sitio. Esto es lo mejor tanto para la seguridad como para el rendimiento, ya que también puede especificar cuántos recursos puede consumir un solo sitio.

    Ver por ejemplo NeverEndingSecurity's Ejecute php-fpm con usuario / uid separado y agrupe en linux. Hay tutoriales como HowtoForge's. Usando PHP-FPM con Apache en Ubuntu 16.04 eso no usa PHP-FPM para aumentar la seguridad a través de la separación del usuario, guiando a usar un solo socket FPM en todo el servidor.


7
2018-05-10 10:03