Configurando permisos de archivos en Drupal

Si piensas que la tecnología puede solucionar tus problemas de seguridad, está claro que ni entiendes los problemas ni entiendes la tecnología 
Bruce Schneier

Si algo puede ser un incordio, son los permisos de los archivos mal configurados, y si este es un CMS el problema puede ser mayor.

Hay muchas configuraciones, muchas opiniones. Un mar de ideas y opiniones derivadas. En resumen más confusión. Por lo que vamos a la base, cuál es la correcta configuración de los permisos de archivo para un servidor?

Googleando, encontré esta discusión en Stack Exchange, donde el usuario @Nic describe muy bien la solución. Y tomo como base para este tutorial.

Consideraciones de seguridad

Lo primero que hay que saber es que usuarios tendrán acceso a los recursos y para que.
Necesitamos un usuario con permisos a las carpetas y sistema del sitio, lo llamaremos weber. El otro usuario del sitio, son los visitantes o administradores del sitio, todos lo que usen el sitio, suban imágenes, etc, y estas las realiza Apache o el servidor HTTP que tengamos instalado. El usuario que se crea en la instalación de Apache, es www-data.
Los archivos .php no necesitan se ejecutables, solo los archivos binarios, scripts de shell o directorios necesitan este permiso.

El usuario weber, estará restringido, permisos mínimos y no tendrá terminal de consola, ya que su función principal es subir archivos por FTP a su carpeta enjaulada para realizar las actualizaciones, cambios de código, nada más, nada de administrar el sistema, de ser necesario lo podríamos escalar para realizar tareas como ejecutar dush. No realizaremos la configuración de weber en este tutorial.

Por lo que podríamos otorgar de esta manera permisos a los desarrolladore/as, diseñadore/as y administradore/as permisos para que suban cambios

El otro usuario es www-data, este solo necesita leer los recursos, eventualmente guardar algún contenido.

Las carpetas y archivos con permisos 777, es una mala idea, ya que le estamos otorgando acceso a los recursos a cualquier usuario con acceso a una consola, por lo que siempre evitaremos este tipo de configuración de permisos.

Configurando permisos

Aquí seguimos los pasos y ejecutamos los comandos descritos en la documentación oficial de Drupal, siempre teniendo en cuenta la configuración que tengamos preparada en nuestro servidor. En mi caso, la carpeta raíz de mi instalación es web/  dentro de esta carpeta ejecutamos:

# chown -R weber:www-data /var/www/web

# cd /var/www/web

# find . -type d -exec chmod u=rwx,g=rx,o= '{}' \;

# find . -type f -exec chmod u=rw,g=r,o= '{}' \;

Con la primera instrucción se asigna al usuario weber y al grupo www-data la propiedad de las carpetas, lo hacemos de forma recursiva a todos los elementos dentro de web/.
Nos movemos a la carpeta raíz, cambiamos los permisos a las carpetas las carpetas, de forma recursiva también, otorgando a usuario permisos de lectura, escritura y ejecución, para el grupo, lectura y ejecución, para los otros nada.
La última instrucción, realiza los cambios de permisos para los ficheros, lectura y escritura para el usuario y solo lectura al grupo. Esta es la estructura básica. Ahora vamos a permitir que el gestor pueda guardar los archivos y cache en la carpeta files dentro del la carpeta sites.

# cd web/sites

# for d in ./*/files
   do
     find $d -type d -exec chmod ug=rwx,o= '{}' \;
     find $d -type f -exec chmod ug=rw,o= '{}' \;
done

Este script nos sitúa en la carpeta sites/, y mediante un loop modifica los permisos que configuramos antes, para todas las carpetas y archivos que encuentre en todas las carpetas files/. Así si se podrá subir contenido al servidor por medio de nuestro sitio.

Es recomendable dejar solo permisos de lectura al archivo site/default/setings.php y site/default/default.setings.php.

# chmod 440 *settings.php

Listo ya tenemos nuestro sitio, con los permisos configurados correctamente. Para mantener la instalación, actualizaciones y otras tareas es mejor usar Drush, ejecutado desde el usuario web, habilitándole una consola temporal .

Y siempre revisar los avisos de seguridad y parches liberados. De nada sirve todo el trabajo, si nos entran por una vulnerabilidad. Para eso inscribirse al newsletter del seguridad de Drupal o seguir su canal de Twitter @drupalsecurity.