it-swarm-es.com

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

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

Tenemos dos usuarios regulares y root. Entonces, al jugar con archivos en /var/www, en lugar de tener que ...

chown -R www-data:www-data

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

Pregunta complementaria: ¿Qué tan duro entonces tienes permisos?

Este siempre ha sido un problema en entornos de desarrollo colaborativo.

218
Gareth

Intentando expandirme en @ Zoredache respuesta , mientras lo intento yo 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 agregar a grupos existentes

    usermod -a -G www-pub userb

    groups usera ## grupos de visualización para el usuario

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

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

  • Cambie los permisos de todas las carpetas a 2775

    chmod 2775 /var/www ## 2 = establecer id del grupo, 7 = rwx para el propietario (root), 7 = rwx para el grupo (www-pub), 5 = rx para el mundo (incluido Apache www-data usuario)

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

    Hay una -R opción recursiva, pero eso no discriminará entre archivos y carpetas, por lo que debe se find , así:

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

  • Cambie todos los archivos a 0664

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

  • Cambie la máscara de usuario para sus usuarios a 0002

    La umask controla los permisos de creación de archivos predeterminados, 0002 significa que los archivos tendrán 664 y directorios 775. Configuración de esto (editando la línea umask 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 directorio y verificando el propietario, el grupo y los permisos con ls -l.

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

209
Tom

No estoy completamente seguro de cómo desea configurar los permisos, pero esto puede darle un punto de partida. Probablemente hay mejores formas. 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 en/var/www a root: www-pub.
  • Cambia los permisos de todas las carpetas a 2775
  • Cambia todos los archivos a 0664.
  • Cambie la máscara de usuario para sus 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 forzará que todos los archivos que se crean sean propiedad del grupo propietario de la carpeta. Es necesario ajustar la umask para asegurarse de que el bit de escritura esté configurado para que cualquier persona del grupo pueda editar los archivos.

En cuanto a qué tan duro voy con permisos. Depende completamente del sitio/servidor. Si solo hay 1-2 editores y solo necesito evitar que rompan las cosas demasiado, entonces lo haré fácil. Si el negocio requería algo más complejo, entonces establecería algo más complejo.

62
Zoredache

Creo que puede encontrar útil POSIX ACL (listas de control de acceso). Permiten un modelo de permisos más fino en comparación con el usuario: grupo: otro modelo. He descubierto que es más fácil mantenerlos 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 los permisos de cada usuario explícitamente:

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

O puede hacerlo en función de algún grupo compartido:

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

Y quizás 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 man:

Tutorial

39
Joe Holloway

Esta pregunta fue pregunta de nuevo , y como discutido en meta, las mejores prácticas actuales ofrecen mejores enfoques que los disponibles en 2009, cuando se hizo esta pregunta. Esta respuesta intenta dar algunas soluciones actuales para manejar entornos de desarrollo web colaborativos de forma segura .


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

  • Tener un usuario separado para cada sitio , es decir, no servir a todos los sitios usando www-data. Esto es importante, ya que hoy en día Apache rara vez sirve únicamente ¡estática archivos de contenido, pero ejecuta ¡dinámico sitios web. Esta respuesta se concentra en PHP ya que es el lenguaje más común del sitio del servidor, pero los mismos principios se aplican también a los demás.

    Si tiene un problema de seguridad en un solo sitio, puede extenderse 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 de la base de datos, y modificar todos los sitios en los que el usuario tiene permisos de escritura.

  • Use ¡Protocolo de transferencia de archivos SSH (SFTP). Mientras usa FTP debe abandonarse por seguridad (ya que envía contraseñas y el contenido en texto plano), es un 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 qué 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 claves SSH para iniciar sesión.

    Cada desarrollador puede generar pares de claves y mantener la clave privada en secreto. Luego, la clave pública se agrega a ~/.ssh/authorized_keys archivo para cada cuenta de usuario del sitio web en la 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 por completo el inicio de sesión basado en contraseña.

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

    Ver p. NeverEndingSecurity's Ejecute php-fpm con usuario/uid y grupo separados en linux . Hay tutoriales como HowtoForge's sando PHP-FPM con Apache en Ubuntu 16.04 que no usa PHP-FPM para aumentar la seguridad a través de la separación del usuario, guiando el uso de un único socket FPM en el servidor.

11
Esa Jokinen