GNU/Linux >> Tutoriales Linux >  >> Linux

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

Solución 1:

Intentando ampliar la respuesta de @Zoredache, 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

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

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

  • Cambiar 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 apache www-data)

    Establecer el bit de ID de grupo (SETGID) (2) hace que el grupo (www-pub) se copie en 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 archivos.

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

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

  • Cambiar todos los archivos a 0664

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

  • Cambie el umask para sus usuarios a 0002

    El umask controla los permisos de creación de archivos predeterminados, 0002 significa que los archivos tendrán 664 y los directorios 775. Al configurar esto (editando el umask línea en la parte inferior de /etc/profile en mi caso) significa que los archivos creados por un usuario podrán ser escritos 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á cerrar sesión/iniciar sesión para que los cambios en sus grupos surtan efecto!

Solución 2:

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 en /var/www a root:www-pub.
  • Cambiar los permisos de todas las carpetas a 2775
  • Cambie todos los archivos a 0664.
  • Cambie el umask 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 tendrá 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 creen 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 lo duro que voy con los permisos. Depende completamente del sitio/servidor. Si solo hay 1-2 editores y solo necesito evitar que rompan demasiado las cosas, lo haré con calma. Si el negocio requiriera algo más complejo, configuraría algo más complejo.

Solución 3:

Creo que puede encontrar POSIX ACL (listas de control de acceso) útiles. Permiten un modelo de permisos más detallado en comparación con el modelo usuario:grupo:otro. Descubrí 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 los permisos de cada usuario de forma explícita:

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 quiera mantener su usuario de Apache como de solo lectura

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

Páginas man:

  • setfacl
  • getfacl

Tutoría

Solución 4:

Esta pregunta se hizo nuevamente y, como se discutió en la meta, las mejores prácticas actuales brindan mejores enfoques que los que estaban disponibles en 2009, cuando se hizo esta pregunta. Esta respuesta intenta brindar algunas soluciones actuales para manejar entornos de desarrollo web colaborativo de forma segura .

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

  • Tener usuarios separados para cada sitio es decir, no sirva todos los sitios usando www-data . Esto es importante, ya que hoy en día Apache rara vez sirve únicamente static archivos de contenido, pero ejecutando dynamic sitios web Esta respuesta se concentra en PHP, ya que es el lenguaje de sitio de servidor más común, pero los mismos principios también se aplican a los demás.

    Si tiene un problema de seguridad en un solo sitio, puede extenderse a todos los sitios que se ejecutan con 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.

  • Usar 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 qué se trata esta pregunta. En lugar de darles las contraseñas de 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 un par de claves y mantener en secreto la clave privada. Luego, la clave pública se agrega al ~/.ssh/authorized_keys archivo para cada cuenta de usuario del sitio web en la que está trabajando el desarrollador. Esto tiene muchas ventajas para administrar las contraseñas y los inicios de sesión:

    • Cada desarrollador puede tener acceso a cualquier cantidad 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 deja la empresa.

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

  • Usar PHP-FPM . Es el enfoque actual para ejecutar PHP como usuario. Crear un nuevo grupo 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.

    Véase, por ejemplo. Ejecutar php-fpm de NeverEndingSecurity con usuario/uid y grupo separados en Linux. Hay tutoriales como HowtoForge's Using PHP-FPM with Apache on Ubuntu 16.04 que no usa PHP-FPM para aumentar la seguridad a través de la separación de usuarios, guiando el uso de un solo socket FPM en todo el servidor.


Linux
  1. ¿Cómo maneja Linux múltiples separadores de rutas consecutivas (/home////username///file)?

  2. UNIX/Linux:¿Cuál es el permiso correcto de los directorios /tmp y /var/tmp?

  3. ¿Cuál es la mejor manera de enviar una señal a todos los miembros de un grupo de procesos?

  4. Acabo de eliminar /bin. ¿Cuál es la mejor manera de recuperarse?

  5. ¿Con qué usuario deberían ejecutarse apache y PHP? ¿Qué permisos deben tener los archivos /var/www?

¿Cuál es la mejor distribución de Linux para principiantes?

La forma correcta de editar archivos /etc/passwd y /etc/group en Linux

/etc/passwd muestra al usuario en un grupo, pero /etc/group no

¿Cuál es la mejor manera de aprender SELinux?

¿Cuál es la diferencia entre /tmp y /run?

¿Deberían vivir los sitios web en /var/ o /usr/ según el uso recomendado?