Languages: English • Español • Français • Português do Brasil • 日本語 中文(简体) • (Add your language)

En los sitemas de computación, los distintos ficheros y directorios pooseen permisos que especifican quien y que puede leer, escribir, modificar y accederlos. Esto es importante puesto que WordPress puede necesitar accesoo de escritura a ficheros en tu directorio wp-content para activar ciertas funcionalidades.

Modalidades de permisos

  7        5      5
(user) (group) (world)
usuario grupo   mundo
 r+w+x   r+x     r+x
 4+2+1   4+2+1   4+2+1  = 755

El modo de permisos se computa sumando los valores para el usuario el grupo de ficheros y para el resto de lso demás. Este diagrama muestra como.

• Read 4 - Permitido leer ficheros/leer directorio
• Write 2 - Permitido escribir/modificar ficheros/directorios
• eXecute1 - Leer/escribir/eliminar/modificar/usar de directorio en el path

  7       4      4
(user) (group) (world)
usuario grupo   mundo
 r+w+x    r      r
 4+2+1  4+0+0  4+0+0  = 744

Ejemplo de modos de permisos

Esquema de permisos para WordPress

Los permisos serán diferentes de un host a otros host, así que esta guía solamente detalla principios genéricos. No puede cubrir todos los casos. Esta guía es válida para servidores que corren una configuración normal (nota: para hosting compartido utilizar métodos "suexec", ver mas abajo).

Típicamente, todos los ficheros deberían pertenecer a tu cuenta (ftp) de usuario de tu servidor web, y deberían ser escribibles por esa cuenta. En hosting compartido, los ficheros nunca deben pertenecer al proceso mismo del servicio web (ciertas veces este es el usuario www, o apache, o nobody).

Cualquier fichero que necesite acceso de escritura desde WordPress debería pertenecer o pertenecer grupalmente a la cuenta de usuario utilizada por WordPress (la cual puede que sea diferente de la cuenta del servidor). Por ejemplo, puede que tengas una cuenta de usuario que te deje usar FTP cargando y descargando ficheros a tu servidor, pero tu servidor mismo puede que use un usuario separado, en un grupo de usuario aparte, tal como dhapache o nobody. Si WordPress se ejecuta como la cuenta de FTP, esa cuenta necesita tener permisos de escritura, p. ej: ser el propietario de los ficheros, o pertenecer a un grupo que tenga permiso de escritura. En este último caso, significaría que los permisos están establecidos más permisivamente que por defecto (por ejemplo, 775 en vez de 755 para directorios(carpetas), y 664 en vez de 644).

Los permisos de fichero y directorio de WordPress deberían ser los mismos para la mayoría de usuarios, dependiendo del tipo de instalación que hayas realizado y la configuración de umask del entorno de sistema en el momento de la instalación.

Típicamente, todos los ficheros del núcleo de WordPress deberían ser escribibles sólamente por tu cuenta de usuario (o la cuenta del demonio httpd, si es diferente). (A pesar de ello algunas veces, se utilizan cuentas ftp múltiples para gestionar una instalación, y si todos los usuarios de ftp son conocidos y de confianza, es decir: no un host compartido, entonces puede ser apropiado asignarlos a un grupo escribible. Pregunta al administrador de tu servidor para saber más.) De todos modos, si utilizas mod_rewrite Permalinks u otras características de .htaccess deberías asegurarte de que WordPress tambieén puede escribir en tu fichero /.htaccess.

Si quieres utilizar el editor incorporado del tema, todos los ficheros necesitan ser grupalmente escribibles. Intenta usarlo antes de modificar los permisos de ficheros, debería funcionar. (Esto puede ser cierto si diferentes usuarios subieron el paquete de WordPress y el Plugin o Tema. No habría ningún problema para los Plugin y Temas instalados vía admin. Al cargar ficheros con diferentes usuarios de ftp se necesita que sea grupalmente escribible. En hosting compartido, asegúrate que el grupo es exclusivo a los usuarios en quienes confíes... el usuario apache no debería estar en ese grupo y no debería poseer ficheros propios.)

Ciertos plugins requieren que el directorio /wp-content/ sea escribible, pero en muchos caso te lo dejarán saber durante su instalación. En algunos casos, esto puede requerir asignar permisos 755. Lo mismo es cierto para /wp-content/cache/ y puede que /wp-content/uploads/ (si estás usando MultiSite es:MultiSitio puede que necesites también hacer esto para /wp-content/blogs.dir/)

Los directorios adicionales bajo /wp-content/ deberían ser documentados por cualquier plugin /tema que los necesite. Los permisos variarán.

/   
|- index.php
|- wp-admin
|   `- wp-admin.css
|- wp-blog-header.php
|- wp-comments-post.php
|- wp-commentsrss2.php
|- wp-config.php
|- wp-content
|   |- cache
|   |- plugins
|   |- themes
|   `- uploads
|- wp-cron.php
|- wp-includes
`- xmlrpc.php

Hosting compartido con suexec

Lo arriba descrito puede que no se aplique a sistemas de hosting compartido que usen la aproximación "suexec" para ejecutar binarios PHP. Esta es una aproximación popular usada por muchos host web. Para estos sistemas, el proceso php corre como el propietario de los propios ficheros, permitiendo una configuración más simple y un entorno más seguro ara el caso específico de hosting compartido.

En tal configuración suexec,el esquema de permisos correctos es simple de entender.

• Todos los ficheros deberían pertenecer a la verdadera cuenta de usuario ftp, no a la cuenta de usuario usada por el proceso demonio httpd.
• la propiedad de grupo es irrelevante, a menos que haya requisitos específicos de grupo para el proceso de comprobación de permisos del servidor web. Esto no es habitualmente el caso.
• Todos los directorios deberían ser 755 o 750.
• Todos los ficheros deberían ser 644 o 640. Excepción: wp-config.php debería ser 600 para prevenir que otros usuarios del servidor lo lean.
• Ningún directorio debería tener nunca los 777, incluso los directorios de carga. Ya que el proceso php se ejecuta como el propietario de los ficheros, consigue los permisos del usuario puede escribir incluso en un directorio 755.

En este tipo de configurción específica, WordPress detectará que puede crear directamente ficheros con la propiedad adecuada, y de ese modo no preguntara por las credenciales de FTP cuando se actualicen o instalen plugins.

Usando un Cliente FTP

programas FTP ("clientes") te permiten establecer permisos a los archivos y directorios en tu host remoto. Esta función se suele llamar chmod or establecer permisos en el menú del programa.

En una instalación de WordPress, dos archivos que es probable que desee modificar son la página de índice y el css que controla el diseño. He aquí cómo cambiar index.php - el proceso es el mismo para cualquier archivo.

En la pantalla de abajo, mira la última columna - que muestra los permisos. Parece un poco confuso, pero por ahora sólo ten en cuenta la secuencia de letras.

Permisos iniciales

Haz clic derecho en 'index.php' y seleccione 'Permisos de archivo'
Aparecerá una pantalla emergente.

Modificando los permisos de archivo

No te preocupes por las casillas de verificación. Simplemente elimina el 'valor numérico:' e introduce el número que necesitas - en este caso es 666. A continuación, haz clic en Aceptar.

Los permisos han sido modificados

Ahora puedes ver que los permisos de archivos se han cambiado.

Unhide the hidden files

By default, most FTP Clients, including FileZilla, keep hidden files, those files beginning with a period (.), from being displayed. But, at some point, you may need to see your hidden files so that you can change the permissions on that file. For example, you may need to make your .htaccess file, the file that controls permalinks, writeable.

To display hidden files in FileZilla, in it is necessary to select 'View' from the top menu, then select 'Show hidden files'. The screen display of files will refresh and any previously hidden file should come into view.

To get FileZilla to always show hidden files - under Edit, Settings, Remote File List, check the Always show hidden files box.

In the latest version of Filezilla, the 'Show hidden files' option was moved to the 'Server' tab. Select 'Force show hidden files.'

Using the Command Line

If you have shell/SSH access to your hosting account, you can use chmod to change file permissions, which is the preferred method for experienced users. Before you start using chmod it would be recommended to read some tutorials to make sure you understand what you can achieve with it. Setting incorrect permissions can take your site offline, so please take your time.

• Unix Permissions
• Apple Chmod Reference

You can make all the files in your wp-content directory writable in two steps, but before making every single file and folder writable you should first try safer alternatives like modifying just the directory. Try each of these commands first and if they dont work then go recursive, which will make even your themes image files writable. Replace DIR with the folder you want to write in

chmod -v 746 DIR
chmod -v 747 DIR
chmod -v 756 DIR
chmod -v 757 DIR
chmod -v 764 DIR
chmod -v 765 DIR
chmod -v 766 DIR
chmod -v 767 DIR

If those fail to allow you to write, try them all again in order, except this time replace -v with -R, which will recursively change each file located in the folder. If after that you still cant write, you may now try 777.

About Chmod

chmod is a unix command that means "change mode" on a file. The -R flag means to apply the change to every file and directory inside of wp-content. 766 is the mode we are changing the directory to, it means that the directory is readable and writable by WordPress and any and all other users on your system. Finally, we have the name of the directory we are going to modify, wp-content. If 766 doesn't work, you can try 777, which makes all files and folders readable, writable, and executable by all users, groups, and processes.

If you use Permalinks you should also change permissions of .htaccess to make sure that WordPress can update it when you change settings such as adding a new page, redirect, category, etc.. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.

1. Go to the main directory of WordPress
2. Enter chmod -v 666 .htaccess

The dangers of 777

The crux of this permission issue is how your server is configured. The username you use to FTP or SSH into your server is most likely not the username used by the server application itself to serve pages.

  7      7      7
 user   group  world
 r+w+x  r+w+x  r+w+x
 4+2+1  4+2+1  4+2+1  = 777

Often the Apache server is 'owned' by the dhapache or nobody user accounts. These accounts have a limited amount of access to files on the server, for a very good reason. By setting your personal files and folders owned by your user account to be World-Writable, you are literally making them World Writable. Now the dhapache and nobody users that run your server, serving pages, executing php interpreters, etc.. will have full access to your user account files.

This provides an avenue for someone to gain access to your files by hijacking basically any process on your server, this also includes any other users on your machine. So you should think carefully about modifying permissions on your machine. I've never come across anything that needed more than 767, so when you see 777 ask why its necessary.

The Worst Outcome

The worst that can happen as a result of using 777 permissions on a folder or even a file, is that if a malicious cracker or entity is able to upload a devious file or modify a current file to execute code, they will have complete control over your blog, including having your database information and password.

Find a Workaround

Its usually pretty easy to have the enhanced features provided by the impressive WordPress plugins available, without having to put yourself at risk. Contact the Plugin author or your server support and request a workaround.

Finding Secure File Permissions

The .htaccess file is one of the files that is accessed by the owner of the process running the server. So if you set the permissions too low, then your server won't be able to access the file and will cause an error. Therein lies the method to find the most secure settings. Start too restrictive and increase the permissions until it works.

Example Permission Settings

The following example has a custom compiled php-cgi binary and a custom php.ini file located in the cgi-bin directory for executing php scripts. To prevent the interpreter and php.ini file from being accessed directly in a web browser they are protected with a .htaccess file.

Default Permissions (umask 022)

644 -rw-r--r--  /home/user/wp-config.php
644 -rw-r--r--  /home/user/cgi-bin/.htaccess
644 -rw-r--r--  /home/user/cgi-bin/php.ini
755 -rwxr-xr-x  /home/user/cgi-bin/php.cgi
755 -rwxr-xr-x  /home/user/cgi-bin/php5.cgi

Secured Permissions

600 -rw-------  /home/user/wp-config.php
604 -rw----r--  /home/user/cgi-bin/.htaccess
600 -rw-------  /home/user/cgi-bin/php.ini
711 -rwx--x--x  /home/user/cgi-bin/php.cgi
100 ---x------  /home/user/cgi-bin/php5.cgi

.htaccess permissions

644 > 604 - The bit allowing the group owner of the .htaccess file read permission was removed. 644 is normally required and recommended for .htaccess files.

php.ini permissions

644 > 600 - Previously all groups and all users with access to the server could access the php.ini, even by just requesting it from the site. The tricky thing is that because the php.ini file is only used by the php.cgi, we only needed to make sure the php.cgi process had access. The php.cgi runs as the same user that owns both files, so that single user is now the only user able to access this file.

php.cgi permissions

755 > 711 This file is a compiled php-cgi binary used instead of mod_php or the default vanilla php provided by the hosting company. The default permissions for this file are 755.

php5.cgi permissions

755 > 100 - Because of the setup where the user account is the owner of the process running the php cgi, no other user or group needs access, so we disable all access except execution access. This is interesting because it really works. You can try reading the file, writing to the file, etc.. but the only access you have to this file is to run php scripts. And as the owner of the file you can always change the permission modes back again.

$ cat: php5.cgi: Permission denied
./php5.cgi:  Welcome

See Also

• Support Forum thread
• htaccess for subdirectories
• Override WordPress Default permissions