Solucionando el problema de permisos de archivos web

Si, como nosotros, desarrolla aplicaciones web y las implementa en servidores Linux (entornos de desarrollo o producción), es posible que se haya preguntado cómo manejar los permisos de archivos en los archivos de la aplicación de una manera simple y sin complicaciones.

Algunos hechos

Los desarrolladores que operan en el servidor requieren permisos de archivos específicos en los archivos de la aplicación para poder leerlos y escribirlos (por razones obvias).

El servidor web (Apache, nginx, Lighttpd, etc.) también requiere permisos de archivos específicos en los archivos de la aplicación para poder leerlos, y para algunos archivos (pero no todos) para poder escribirlos (como por ejemplo , al cargar un archivo, o al crear una miniatura, etc.)

El problema

Tanto el servidor web como los desarrolladores requieren permisos de archivos en los mismos archivos para funcionar correctamente, pero pueden necesitar permisos diferentes en los mismos archivos.

Los desarrolladores requieren la capacidad de leer y escribir cada archivo, mientras que el servidor web puede requerir solo permisos de escritura en algunos archivos.

Este problema limitado de recursos compartidos puede convertirse rápidamente en una pesadilla para la persona a cargo del servidor.

La solución del usuario ~ grupo (defectuoso)

Una solución común es dar a los desarrolladores el mismo grupo de usuarios que el servidor web (algo así como www-data), y luego hacer malabarismos con la propiedad de los archivos.

Si bien esto funciona de alguna manera, es defectuoso en otros:

• Problema de concurrencia: cuando un desarrollador crea un archivo, el desarrollador lo posee y es posible que el proceso del servidor web no lo pueda leer (ni modificar si es necesario) (se concede que se podría usar algún sistema de ACL en el FS, pero ¿Alguna vez ha conseguido que esto funcione correctamente?
• problema de impermeabilidad : si tiene varias aplicaciones web funcionando en paralelo en su servidor web, tendrá que hacer malabarismos mucho más con grupos y subgrupos solo para evitar que el Desarrollador A pueda ver y modificar la Aplicación B.
• problema de estabilidad con el tiempo, y de acuerdo con el principio de aumento de la entropía , los permisos de archivos se convertirán en un desastre y se producirán errores relacionados con la permanente.

Nuestra (asombrosa) solución

¿No sería genial si un desarrollador pudiera leer y escribir archivos de una aplicación con su propio usuario / grupo no compartido, mientras que permite que el servidor web tenga sus propios permisos y permisos desatornillables para el desarrollador en los archivos de dicha aplicación?

Bueno, sí, lo sería, y eso es exactamente para lo que está destinado bindfs.

Con bindfs , los desarrolladores acceden a las aplicaciones a través de puntos de montaje dedicados (colocados en su directorio local), actuando como filtros de permisos de archivos, presentando archivos como si fueran propios, mientras que los archivos son realmente propiedad del usuario del servidor web (like www-data).

Ventajas:

• resuelve el problema de simultaneidad , ya que cada usuario de la ecuación (todos los desarrolladores y el servidor web) ve los permisos que requiere para operar de manera adecuada y segura;
• resuelve el problema de impermeabilidad , como si necesitaras que un desarrollador accediera a una aplicación en particular, tienes que agregar un punto de montaje en su directorio de inicio, pero por el contrario, si necesitas que un desarrollador no acceda a una aplicación en particular, solo tienes que para no agregar dicho punto de montaje en su directorio de inicio.
• resuelve el problema de estabilidad , ya que los desarrolladores nunca podrán cambiar los permisos de archivos establecidos en los archivos de la aplicación, tal como lo requiere el servidor web para operar de forma adecuada y segura.
• ¡Lo mejor de todo es que es simple de entender y configurar!

Como usar esto

Para sistemas Ubuntu / Debian

En el siguiente ejemplo, suponemos que el usuario desarrollador es devone, el usuario del servidor web es www-datay la aplicación está almacenada en /var/www/application1.


# Installing bindfs (just the first time) root@netgusto $ apt-get update
root@netgusto $ apt-get -y install bindfs
# Creating the application mountpoint
root@netgusto $ mkdir -p /home/devone/websites/application1
root@netgusto $ chown -Rf devone:devone /home/devone/websites

Luego, edite el contenido de / etc / fstab y agregue esta línea (solo una línea, sin ajustes de línea):

bindfs#/var/www/application1 /home/devone/websites/application1 fuse force-user=devone,force-group=devone,create-for-user=www-data,create-for-group=www-data,create-with-perms=0770,chgrp-ignore,chown-ignore,chmod-ignore 0 0  

Guarde el archivo y proceda con la aplicación de montaje (se montará automáticamente al cargar el sistema):

root@netgusto $ mount /home/devone/websites/application1

Si su sistema grita force-usero force-groupno se define:

• reemplazar force-userporowner
• reemplazar force-groupporgroup

Probando la solución

Una vez que la aplicación está montada, puede probarla creando un archivo en el punto de montaje de la aplicación usando la devonecuenta y verificando las permanentes del archivo:

# as root
root@netgusto $ su - devone

# as devone
devone@netgusto $ cd ~/websites/application1  
devone@netgusto $ touch helloworld.txt  
devone@netgusto $ ls -l helloworld.txt  
-rwxrwx--- 1 devone devone 0 sept. 10 17:15 helloworld.txt
devone@netgusto $ exit

# as root again
root@netgusto $ cd /var/www/application1  
root@netgusto $ ls -l helloworld.txt  
-rwxrwx--- 1 www-data www-data 0 sept. 10 17:15 helloworld.txt

El archivo es propiedad de www-data:www-datamientras que nosotros lo creamos como devone:devone! Funcionó !

Una cosa más

Si desea evitar que los desarrolladores accedan /var/www/application1directamente, solo tiene que ejecutar esto:

# Attribute the /var/www root dir to www-data:www-data
root@netgusto $ chown www-data:www-data /var/www

# Change the permissions so that only the web server can enter this dir
root@netgusto $ chmod 770 /var/www

Tenga en cuenta que el directorio web servido /var/www/application1no tiene nada que ver con bindfs , por lo que no debería afectar en absoluto asu servidor web.

Cuan genial es eso ? Dinos qué piensas !

¿Por qué no suscribirse a nuestro boletín y
estar informado de nuestras ofertas exclusivas y próximas publicaciones? Introduce tu correo electronico.
Haz clic en el botón de abajo.
[mailpoet_form id=»1″]