Topics

  • Permission Modes
    • Example Permission Modes
  • Permission Scheme for WordPress
    • Shared Hosting with suexec
  • Using an FTP Client
    • Unhide the subconscious files
  • Using the Command Line
    • About Chmod
  • The dangers of 777
    • The Worst Event
    • Find a Workaround
  • Finding Secure File Permissions
    • Example Permission Settings
      • .htaccess permissions
      • php.ini permissions
      • php.cgi permissions
      • php5.cgi permissions
    • SELinux
      • How to determine if selinux is the problem?
    • See Also

On computer file systems, dissimilar files and directories havepermissions that specify who and what can read, write, change and access them. This is important because WordPress may need access to write to files in yourwp-content directory to enable certain functions.

Permission Modes

                  7       five    v  user   group  world  r+westward+x  r+x    r+x  four+2+i  4+0+1  4+0+1 = 755

The permission mode is computed by calculation upwardly the following values for the user, the file group, and for everyone else. The diagram shows how.

  • Read 4 – Allowed to read files
  • Write ii – Allowed to write/modify files
  • eXecute1 – Read/write/delete/modify/directory
                  seven       4     iv  user   grouping  world  r+due west+x    r      r  4+ii+ane  4+0+0 four+0+0  = 744

Peak ↑

Case Permission Modes

Mode Str Perms Caption
0477 -r–rwxrwx owner has read only (iv), other and group has rwx (7)
0677 -rw-rwxrwx owner has rw simply(six), other and group has rwx (7)
0444 -r–r–r– all accept read simply (iv)
0666 -rw-rw-rw- all have rw only (half dozen)
0400 -r——– possessor has read only(4), grouping and others have no permission(0)
0600 -rw——- owner has rw merely, group and others accept no permission
0470 -r–rwx— possessor has read but, group has rwx, others accept no permission
0407 -r—–rwx possessor has read only, other has rwx, group has no permission
0670 -rw-rwx— owner has rw only, group has rwx, others accept no permission
0607 -rw—-rwx owner has rw only, group has no permission and others have rwx

Superlative ↑

Permission Scheme for WordPress

Permissions will be different from host to host, then this guide only details general principles. It cannot cover all cases. This guide applies to servers running a standard setup (note, for shared hosting using "suexec" methods, see beneath).

Typically, all files should be owned past your user (ftp) account on your web server, and should exist writable past that account. On shared hosts, files should never be endemic by the webserver procedure itself (sometimes this iswww, orapache, ornobody user).

Any file that needs write access from WordPress should be owned or group-owned past the user business relationship used by WordPress (which may exist dissimilar than the server account). For example, y'all may have a user account that lets you FTP files back and forth to your server, just your server itself may run using a divide user, in a split usergroup, such equallydhapache ornobody. If WordPress is running every bit the FTP business relationship, that account needs to have write access, i.e., be the owner of the files, or vest to a group that has write access. In the latter case, that would hateful permissions are gear up more than permissively than default (for example, 775 rather than 755 for folders, and 664 instead of 644).

The file and binder permissions of WordPress should be the same for most users, depending on the type of installation you performed and the umask settings of your system environment at the time of install.

NOTE: If an experienced user installed WordPress for you, y'all likely do not need to modify file permissions. Unless you are experiencing issues with permission errors, or youswant to, y'all probably should non mess with this.

NOTE: If you installed WordPress yourself, yous probable Do need to modify file permissions. Some files and directories should be "hardened" with stricter permissions, specifically, the wp-config.php file. This file is initially created with 644 permissions, and it'southward a risk to get out information technology like that. See Security and Hardening.

Typically, all core WordPress files should be writable only by your user account (or the httpd account, if different). (Sometimes though, multiple ftp accounts are used to manage an install, and if all ftp users are known and trusted, i.due east., non a shared host, so assigning group writable may exist appropriate. Enquire your server admin for more info.) However, if you utilise mod_rewrite Permalinks or other .htaccess features you should brand sure that WordPress can too write to your/.htaccess file.

If y'all want to use the built-in theme editor, all files need to be group writable. Attempt using information technology earlier modifying file permissions, it should work. (This may be true if different users uploaded the WordPress package and the Plugin or Theme. This wouldn't be a problem for Plugin and Themes installed via the admin. When uploading files with different ftp users group writable is needed. On shared hosting, make sure the group is exclusive to users y'all trust… the apache user shouldn't be in the group and shouldn't own files.)

Some plugins require the /wp-content/ folder be fabricated writeable, but in such cases they volition let you know during installation. In some cases, this may crave assigning 755 permissions. The same is true for/wp-content/cache/ and maybe/wp-content/uploads/ (if yous're using MultiSite you may also need to do this for/wp-content/blogs.dir/)

Additional directories nether /wp-content/ should be documented by whatsoever plugin / theme requires them. Permissions will vary.

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

Elevation ↑

Shared Hosting with suexec

The above may non utilise to shared hosting systems that use the "suexec" approach for running PHP binaries. This is a popular approach used by many web hosts. For these systems, the php process runs equally the owner of the php files themselves, assuasive for a simpler configuration and a more than secure environment for the specific instance of shared hosting.

Note: suexec methods should NEVER exist used on a single-site server configuration, they are more securemerely for the specific case of shared hosting.

In such an suexec configuration, the right permissions scheme is simple to understand.

  • All files should be owned past the actual user's business relationship, not the user account used for the httpd process.
  • Grouping ownership is irrelevant, unless there's specific group requirements for the spider web-server procedure permissions checking. This is not usually the instance.
  • All directories should be 755 or 750.
  • All files should be 644 or 640. Exception: wp-config.php should be 440 or 400 to prevent other users on the server from reading it.
  • No directories should always exist given 777, even upload directories. Since the php process is running equally the possessor of the files, information technology gets the owners permissions and can write to even a 755 directory.

In this specific type setup, WordPress will find that information technology tin can directly create files with the proper ownership, so information technology volition not inquire for FTP credentials when upgrading or installing plugins.

Popular methods used past sysadmins for this setup are:

  • suPHP, runs through php-cgi, currently unmaintained since 2013.
  • mod_ruid2, apache module, currently unmaintained since 2013.
  • mpm-itk, apache module.
  • mod_fcgid, an Apache module and FastCGI server with more than extensive configuration.
  • PHP-FPM, an alternative FastCGI server with shared OPCode, for employ with Apache and Nginx.

Top ↑

Using an FTP Client

FTP programs ("clients") permit yous to set permissions for files and directories on your remote host. This role is often calledchmod orset permissions in the program card.

In WordPress install, two files that you will probably want to alter are the alphabetize page, and the css which controls the layout. Here's how y'all alter index.php –the process is the same for whatever file.

In the screenshot below, look at the last cavalcade – that shows the permissions. It looks a fleck disruptive, merely for at present only note the sequence of messages.

Initial permissions

Right-click 'alphabetize.php' and select 'File Permissions'
A popup screen will appear.

Altering file permissions

Don't worry almost the check boxes. Just delete the 'Numeric value:' and enter the number you lot need – in this case it's 666. Then click OK.

Permissions have been altered.

You can now come across that the file permissions take been changed.

Top ↑

Unhide the hidden files

By default, almost FTP Clients, including FileZilla, go on subconscious files, those files beginning with a catamenia (.), from existence displayed. But, at some indicate, you may demand to see your hidden files and so that yous tin modify the permissions on that file. For instance, you may need to make your .htaccess file, the file that controls permalinks, writeable.

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

To become FileZilla to always show subconscious files – under Edit, Settings, Remote File List, check the Always evidence subconscious files box.

In the latest version of Filezilla, the 'Bear witness hidden files' choice was moved to the 'Server' tab. Select 'Force show hidden files.'

Summit ↑

Using the Control Line

If yous have beat/SSH access to your hosting account, yous can applychmod to modify file permissions, which is the preferred method for experienced users. Earlier you start usingchmod it would be recommended to read some tutorials to make sure you understand what you tin attain with it. Setting incorrect permissions tin take your site offline, and then delight take your fourth dimension.

  • Unix Permissions

You can brandall the files in yourwp-content directory writable in ii steps, but before making every single file and folder writable y'all should commencement try safer alternatives similar modifying simply the directory. Try each of these commands first and if they don't work and so go recursive, which volition make even your themes image files writable. Replace DIR with the binder you desire to write in

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

If those fail to permit you lot to write, endeavor them all once more in order, except this time supersede -v with -R, which will recursively change each file located in the folder. If after that you still cant write, you may at present try 777.

Top ↑

About Chmod

chmod is a unix command that means "changemode" on a file. The-R flag means to utilize the change to every file and directory inside ofwp-content. 766 is the fashion nosotros are changing the directory to, information technology means that the directory is readable and writable past WordPress and whatsoever and all other users on your system. Finally, we accept 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 y'all use Permalinks you should also modify permissions of .htaccess to make sure that WordPress tin can update it when yous modify settings such every bit calculation 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. Enterchmod -v 666 .htaccess

NOTE: From a security standpoint, even a pocket-sized corporeality of protection is preferable to a world-writeable directory. First with low permissive settings like 744, working your way up until it works. Only use 777 if necessary, and hopefully only for a temporary amount of time.

Height ↑

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 near likely non the username used by the server application itself to serve pages.

                  vii      7      vii  user   grouping  earth  r+due west+10  r+w+ten  r+w+x  4+2+ane  4+two+i  4+2+one  = 777

Frequently the Apache server is 'owned' by theworld wide web-data,dhapache ornobody user accounts. These accounts have a express amount of access to files on the server, for a very good reason. By setting your personal files and folders endemic by your user business relationship to exist World-Writable, you are literally making them Globe Writable. Now the www-data, 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 artery for someone to gain access to your files past hijacking basically any process on your server, this as well includes any other users on your machine. So you lot should recollect carefully about modifying permissions on your car. I've never come up across anything that needed more than 767, and then when you see 777 ask why it'due south necessary.

Elevation ↑

The Worst Outcome

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

Top ↑

Observe a Workaround

Information technology is normally pretty easy to have the enhanced features provided by the impressive WordPress plugins available, without having to put yourself at risk. Contact the Plugin writer or your server support and asking a workaround.

Top ↑

Finding Secure File Permissions

The .htaccess file is 1 of the files that is accessed by the possessor of the process running the server. So if you set the permissions likewise depression, and 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. Beginning as well restrictive and increase the permissions until it works.

Top ↑

Example Permission Settings

The post-obit example has acustom compiled php-cgi binary and acustom php.ini file located in the cgi-bin directory for executing php scripts. To foreclose 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--  /abode/user/cgi-bin/php.ini 755 -rwxr-xr-10  /home/user/cgi-bin/php.cgi 755 -rwxr-xr-x  /dwelling house/user/cgi-bin/php5.cgi

Secured Permissions

600 -rw-------  /dwelling house/user/wp-config.php half-dozen04 -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------  /abode/user/cgi-bin/php5.cgi

Peak ↑

.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.

Height ↑

php.ini permissions

644 > 600 – Previously all groups and all users with access to the server could access the php.ini, even past but requesting it from the site. The tricky matter is that because the php.ini file is only used past the php.cgi, nosotros but needed to make certain 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.

Top ↑

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.

Summit ↑

php5.cgi permissions

755 > 100 – Because of the setup where the user business relationship is the possessor of the procedure running the php cgi, no other user or group needs access, then nosotros disable all admission except execution admission. This is interesting considering it really works. You can attempt reading the file, writing to the file, etc. but the simply access you lot take to this file is to run php scripts. And as the owner of the file yous tin always change the permission modes back again.

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

Top ↑

SELinux

Security Enhanced linux is a kernel security module that provides mechanisms by which processes can be sandboxed into particular contexts. This is of particular employ to limit the actions that web pages can perform on other parts of the operating system. Actions that are denied by the security policy are often hard to distinguish from regular file permission errors.

selinux is typically installed on Redhat family distributions (due east.g., CentOS, Fedora, Scientific, Amazon and others).

Top ↑

How to determine if selinux is the problem?

If y'all are on a debian based distribution, you lot are probably fine.

Run the following control (on rpm based systems);

# rpm -qa | grep selinux selinux-policy-targeted-iii.13.1-166.el7_4.vii.noarch selinux-policy-3.13.1-166.el7_4.7.noarch libselinux-2.5-11.el7.x86_64 libselinux-python-two.5-eleven.el7.x86_64 libselinux-utils-2.5-xi.el7.x86_64

and to check whether it is the cause of denials of permissions:

# getenforce Enforcing

One issue that selinux causes is blocking the wp-admin tools from writing out the `.htaccess` file that is required for url rewriting. There are several commands for inspecting this behaviour

# audit2allow -w -a type=AVC msg=audit(1517275570.388:55362): avc:  denied  { write } for  pid=11831 comm="httpd" path="/var/www/case.org/.htaccess" dev="vda1" ino=67137959 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file         Was caused by:         The boolean httpd_unified was set incorrectly.         Description:         Allow httpd to unified          Let access by executing:         # setsebool -P httpd_unified i

and

# ausearch -m avc -c httpd ---- time->Tue January 30 01:30:31 2018 type=PROCTITLE msg=audit(1517275831.762:55364): proctitle=2F7573722F7362696E2F6874747064002D44464F524547524F554E44 type=SYSCALL msg=inspect(1517275831.762:55364): curvation=c000003e syscall=21 success=no leave=-13 a0=55b9c795d268 a1=2 a2=0 a3=1 items=0 ppid=11826 pid=11829 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 central=(null) type=AVC msg=audit(1517275831.762:55364): avc:  denied  { write } for  pid=11829 comm="httpd" name="bioactivator.org" dev="vda1" ino=67137958 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:httpd_sys_content_t:s0 tclass=dir ----


You can temporarily disable selinux to determine if it is the cause of the issues;

# setenforce usage:  setenforce [ Enforcing | Permissive | 1 | 0 ]

Top ↑

See Besides

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