chmod 777

Mario González - Blog sobre desarrollo web

El artículo definitivo sobre WordPress y los permisos de carpetas

Has pasado por esto multitud de veces. Instalas un WordPress, y ahí está, mirándote, la dichosa carpeta uploads (bueno, aún no está, pero sabes que aparecerá en cualquier momento). Te preguntas, como siempre, qué hacer en esta ocasión. La tentación de usar sudo y darle permisos 777 a la carpeta es muy grande. Sabes que no es recomendable y que es un agujero de seguridad, pero has intentado varias veces entender cómo funciona eso de los permisos y nunca te acabas de enterar. ¿Entras otra vez en google y te paseas por foros de frikis linuxeros que se pelean entre ellos para enterarte de una vez qué deberías hacer con la carpeta uploads? ¿O recurres, una vez más, al mágico sudo y al mágico chmod 777 para resolver todos tus problemas? En vez de eso, te invito a que leas este artículo donde probablemente te quede un poco más claro todo esto de los permisos.

Puede que no te hayas tenido que pelear con esto nunca. Si eres usuario de Windows y tus webs están alojadas en hostings compartidos, probablemente no tengas problemas con los permisos y este artículo no te sea útil. En el caso de algunas configuraciones de Mac OS X tampoco hay que lidiar con los permisos. Pero si trabajas con Linux y, sobre todo, si tu web no va a estar alojada en un hosting compartido, en algún momento te enfrentarás a ellos.

En cualquiera de los casos, si quieres entender cómo funcionan los permisos en los sistemas UNIX (la mayoría de las webs están alojadas en uno), aquí tienes un post mascadito.

TL;DR

Si tu único problema es que tienes un WordPress alojado en un servidor compartido y no te deja subir archivos a la biblioteca de medios, y además no te apetece leer un post sobre cómo funcionan los permisos, probablemente tu solución sea rápida.

Conéctate al servidor mediante tu cliente de FTP, entra en la carpeta wp-content y haz clic con el botón derecho sobre la subcarpeta uploads. En el menú que se despliega, elige la opción Permisos de archivo (así se llama la opción en el FileZilla, si usas otro cliente probablemente tengas una opción semejante). Puedes olvidarte de los checkboxes, en la casilla Valor numérico pon 775, y acuérdate de marcar «Incluir todos los subdirectorios». Lo importante es no poner nunca un número mayor a 5 en la tercera posición. Con esto es muy probable que se solucione tu problema y tendrás un entorno relativamente seguro.

Permisos FTP

Si quieres aprender cuál es la lógica detrás de esa solución, sigue leyendo.

Usuarios y grupos

Lo que vamos a explicar es aplicable a casi todos los sistemas basados en UNIX, pero es posible que haya distribuciones Linux o versiones de OS X que tengan algunas particularidades o diferencias. Si es tu caso, ya sabes, Google es tu amigo.

Cuando se crea un archivo nuevo o una carpeta nueva, su propietario (owner) es el usuario con el que se ha creado. Por ejemplo, si nuestro usuario es mariogl, nos descargamos la última versión de WordPress y la descomprimimos, los archivos y carpetas resultantes pertenecen a nuestro usuario, es decir, mariogl es el owner. Si en vez de estar en local, estamos conectados por SSH al servidor, o hemos subido los archivos por FTP, todo funciona igual. El propietario de esos archivos será el usuario con el que nos hemos conectado al SSH o el usuario con el que nos hemos conectado al FTP.

Además del propietario, un fichero o una carpeta pertenecen siempre a un grupo de usuarios. Si nos hemos descargado el WordPress y lo hemos descomprimido, esos archivos pertenecen a un grupo que se llama igual que nuestro usuario (por cada usuario suele existir siempre un grupo con el mismo nombre). Si ahora listamos los archivos desde consola con ls -l, veremos algo así:

Listado permisos

En las columnas tercera y cuarta vemos repetido el nombre de usuario. Eso quiere decir que esos ficheros y carpetas que vemos pertenecen al usuario mariogl y también al grupo mariogl. La tercera columna nos da el propietario, y la cuarta nos da el grupo.

Hasta aquí todo es normal. El problema viene cuando vamos a nuestro navegador y queremos que WordPress escriba archivos en el disco duro, por ejemplo, al borrar un plugin, al instalar un theme, al subir una imagen a la biblioteca de medios o al modificar el .htaccess tras cambiar la estructura de enlaces permanentes.

Cuando estamos viendo nuestra web en un navegador, esa web nos la está sirviendo el Apache con su usuario, que es distinto de nuestro usuario. El usuario de Apache (el servidor que entrega las webs a nuestro navegador) suele ser www-data, aunque puede ser otro dependiendo de la distribución. Lo que ocurre entonces es que cuando le pedimos a WordPress que haga alguna operación, como grabar una imagen nueva que hemos subido, la hace con el usuario www-data, pero nuestras carpetas pertenecen al usuario mariogl y al grupo mariogl, por lo tanto WordPress no podrá subir la imagen y dará un error de permisos.

¿Y cómo le damos permiso a WordPress, es decir, al usuario www-data, para que pueda escribir en las carpetas?

Los comandos chmod, chown y chgrp

Lo que se suele hacer en sistemas UNIX en los que varios usuarios (en nuestro ejemplo hay dos, mariogl y www-data pero puede haber un equipo de personas trabajando en la misma web) tienen que tener acceso a unos ficheros, en vez de darle los permisos a cada uno de los usuarios, se les da permisos a los grupos y se mete a los usuarios en los grupos que queramos. Me explico mejor: imaginad que creamos un grupo al que llamamos web.

Podemos hacer que todos los archivos y carpetas que queramos que sean escribibles por WordPress pertenezcan al grupo web, independientemente de qué usuario sea el propietario de esos archivos y carpetas. Luego, le damos al grupo web permisos de escritura para los ficheros y carpetas que queramos, por ejemplo, la carpeta uploads o el fichero .htaccess.

Esto lo haremos en dos pasos. Primero los asignaremos al grupo:


chgrp web .htaccess
chgrp -R web wp-content/uploads

Estos comandos los lanzaríamos desde el directorio raíz del WordPress. Con la primera línea asignamos al grupo web el archivo .htaccess, y con la segunda asignamos al grupo web la carpeta uploads y todas sus subcarpetas (eso significa ese -R). Lo más probable es que en vuestro sistema no haya ningún grupo llamado web, así que os devolverá un error. Dejadme avanzar un poco más y luego volvemos sobre esto.

Una vez asignados, vamos a darle permisos de escritura al grupo:


chmod g+w .htaccess
chmod -R g+w wp-content/uploads

Lo que hemos hecho es darle permisos de escritura al grupo web sobre el archivo .htaccess y la carpeta uploads. Es decir, permitimos que cualquier usuario que pertenezca al grupo web pueda modificar o eliminar el archivo .htaccess y pueda crear, modificar o eliminar archivos dentro de la carpeta uploads y sus subcarpetas. ¿Y si en vez de usar un grupo que no existe, usamos un grupo que ya existe? Pues es lo que haremos, usaremos el grupo www-data (recordad que el Apache utiliza el usuario www-data, y que por cada usuario hay un grupo con el mismo nombre):


chgrp www-data .htaccess
chgrp -R www-data wp-content/uploads

Hemos asignado el archivo .htaccess y la carpeta uploads al grupo www-data. Como, además, antes le hemos dado al grupo permisos de escritura sobre ese archivo y esa carpeta, ahora mismo cualquier usuario perteneciente al grupo www-data tendrá permisos de escritura sobre ellos. Si hacemos ahora ls -l wp-content && ls -la .htaccess (-a es para que muestre el .htaccess, que es un archivo oculto), veremos:

Permisos grupo

Con esto hemos conseguido que WordPress pueda escribir sobre .htaccess y uploads. Nosotros también podremos hacerlo porque somos los propietarios. Y si necesitamos que haya más desarrolladores que puedan escribir en esos archivos, sólo tenemos que añadir sus usuarios al grupo www-data.

Resumiendo este apartado: los ficheros y directorios siempre pertenecen a un propietario y a un grupo, y podemos establecer qué permisos les damos a ambos. El usuario www-data es que el utiliza Apache, por tanto, podemos decir que es el que usa nuestro WordPress. Si hacemos que todos los archivos pertenezcan al grupo www-data, y sólo los que nos interesan tengan permisos de escritura para el grupo, estamos consiguiendo que el WordPress pueda mostrar las páginas y que pueda escribir donde nos interesa.

Lo más probable es que con esto ya tengas una mínima idea de qué hacer para que tu WordPress funcione bien a nivel de permisos. Si quieres saber un poco más, aún queda artículo.

Las triadas de permisos

Al hacer un listado con ls -l, te habrás fijado en que cada archivo/directorio tiene diez caracteres en la primera columna. Del primero nos vamos a olvidar. A grandes rasgos, nos dice si es un archivo (-) o un directorio (d), aunque en realidad puede llevar más valores. Pero fijémonos en los restantes nueve caracteres.

En esas posiciones restantes, los caracteres se agrupan de tres en tres: la triada de usuario, la triada de grupo y la triada de otros.


-rwxr-xr--  5  mariogl www-data  2297  may   7 00:01 .htaccess

En la información anterior sobre el fichero .htaccess, si hacemos la división que acabamos de explicar:
-: es un fichero
rwx: el propietario tiene permisos de lectura (read), escritura (write) y ejecución (execution)
r-x: el grupo tiene permisos de lectura y de ejecución (no tiene permisos de escritura)
r--: el resto de usuarios (los que no pertenecen al grupo ni son propietarios, es decir, los otros) sólo tiene permisos de lectura.

Cuando en el apartado anterior hacíamos chmod g+w .htaccess, lo que estábamos diciendo en realidad era «dale permisos de escritura al grupo». La g sirve para decir que lo que viene después hay que hacerlo para el grupo, si quisiéramos hacerlo para el usuario utilizaríamos la u, y si lo quisiéramos hacer para otros, utilizaríamos la o. El signo + es para otorgarle un permiso. Si quisiéramos quitárselo, utilizaríamos el signo -. Y por último, la w es el permiso que queremos agregar o quitar. Se pueden acumular varios en un mismo comando. Veamos varios ejemplos:


chmod u+w .htaccess    # Le damos permiso de escritura al propietario
chmod g-x .htaccess    # Le quitamos permiso de ejecución al grupo
chmod go-w .htaccess   # Les quitamos permiso de escritura al grupo y a otros

También podemos establecer los permisos de manera absoluta diciéndole cuáles queremos que tenga, independientemente de los que tuviera hasta ahora, utilizando el símbolo =:


chmod u=rwx .htaccess   # Permisos de lectura, escritura y ejecución para el propietario
chmod g=rx .htaccess    # Permisos de lectura y ejecución para el grupo
chmod go=r .htaccess    # Permiso de lectura para el grupo y para otros

¿Y el famoso 777?

Y por fin llegamos a nuestro amigo, el solucionador de todos los problemas.

Las tres letras que identifican los permisos (r, w y x) tienen su equivalente numérico:


--- => 0
--x => 1
-w- => 2
r-- => 4
-wx => 3
r-x => 5
rw- => 6
rwx => 7

Vemos varios ejemplos aplicados a las tres triadas:


rwxr-xr-- => 754
r-xr-xr-x => 555
rwxrwx--- => 770
rwxrw-rw- => 766
rwxrwxrwx => 777   # ¡Ajá!

Aquí podemos ver qué significa darle permisos 777 a un directorio: es como darle permisos rwxrwxrwx, es decir, el propietario puede leer, escribir y ejecutar; el grupo puede leer, escribir y ejecutar; otros pueden leer, escribir y ejecutar. Básicamente, estamos dándole permisos a cualquiera para modificar o borrar cosas.

Cuándo usar sudo

En los ejemplos que hemos visto no aparece por ninguna parte sudo. Esto es porque somos propietarios de los archivos y carpetas que hemos usado. Si no somos propietarios y queremos cambiar el grupo o los permisos, lo tendremos que hacer mediante sudo:


sudo chown mariogl .htaccess
sudo chmod g+w .htaccess

El sistema nos pedirá nuestra contraseña de usuario y nos permitirá aplicar los comandos.

Más información

El objetivo de este artículo no es ahondar en toda la complejidad del sistema de permisos. Por eso nos hemos dejado fuera, adrede, cosas tan importantes como el SGID o umask. Aquí os dejo un link donde está bien explicado.

La idea es aprender a dejar listo un WordPress para que se puedan actualizar plugins, themes, enlaces permanentes, imágenes de la biblioteca multimedia… sin dejar el sistema de archivos expuesto. A partir de aquí, hay configuraciones más o menos seguras, que dependerán del grado de acceso al servidor que tengamos, de si la web sólo la mantiene un usuario o hay varios, de si éstos tocan el servidor o no (lo más recomendable es usar un control de versiones y que los desarrolladores contribuyan a un repositorio). Si tenéis alguna propuesta o veis algún error garrafal en lo que se ha explicado, podéis comentar más abajo.

P.D.: El título del artículo es broma. Esperemos que éste no sea el definitivo.

¿Qué opinas?

Tu dirección de correo electrónico no será publicada. * Campos obligatorios