-
Star
(153)
You must be signed in to star a gist -
Fork
(58)
You must be signed in to fork a gist
-
-
Save macbleser/9136424 to your computer and use it in GitHub Desktop.
#!/bin/bash | |
# | |
# This script configures WordPress file permissions based on recommendations | |
# from http://codex.wordpress.org/Hardening_WordPress#File_permissions | |
# | |
# Author: Michael Conigliaro | |
# | |
WP_OWNER=changeme # <-- wordpress owner | |
WP_GROUP=changeme # <-- wordpress group | |
WP_ROOT=/home/changeme # <-- wordpress root directory | |
WS_GROUP=changeme # <-- webserver group | |
# reset to safe defaults | |
find ${WP_ROOT} -exec chown ${WP_OWNER}:${WP_GROUP} {} \; | |
find ${WP_ROOT} -type d -exec chmod 755 {} \; | |
find ${WP_ROOT} -type f -exec chmod 644 {} \; | |
# allow wordpress to manage wp-config.php (but prevent world access) | |
chgrp ${WS_GROUP} ${WP_ROOT}/wp-config.php | |
chmod 660 ${WP_ROOT}/wp-config.php | |
# allow wordpress to manage .htaccess | |
touch ${WP_ROOT}/.htaccess | |
chgrp ${WS_GROUP} ${WP_ROOT}/.htaccess | |
chmod 664 ${WP_ROOT}/.htaccess | |
# allow wordpress to manage wp-content | |
find ${WP_ROOT}/wp-content -exec chgrp ${WS_GROUP} {} \; | |
find ${WP_ROOT}/wp-content -type d -exec chmod 775 {} \; | |
find ${WP_ROOT}/wp-content -type f -exec chmod 664 {} \; |
If you are having "No such file or directory" problems and you use windows to upload the file a quick fix is changing the format to unix again:
#vim fix_permision.sh
:set fileformat=unix
:wq
#sh fix_permision.sh
I'm on docker and had permission issues when trying to update or install a plugin.
I used this script with this config and want to leave some pointer as this issue might not be obvious to others, especially WS_GROUP. At least, it wasn't for me.
WP_OWNER=my_user_on_host_machine
WP_GROUP=my_user_group_on_host_machine # same name as previous in my case
WP_ROOT=/path/to/wordpress/src
WS_GROUP=http # docker web user on host machine
http
is the apache process created by Docker in my host. I can see http
in ps aux
when the Docker WordPress container is running.
Curiously however, when I go inside the Docker container running WordPress (guest), I see the web user is www-data. The WordPress image I'm running is wordpress:5.4-php7.3-apache.
At any rate, my permission issues went away with the config above, with http.
The number of times I have come back to this page is insane lol.
Landed here to fix a perm issue, so not sure if 1) I messed up script somehow haha, absolutely possible, 2) think the mess up may be still trying to wrap my head around litespeed entirely! Anyone have more wisdom than I? Seems nobody is WS_GROUP as default script has, but ran script and still issues with images not showing, but after script site has critical error... Setting back to basic 755 / 644 brings it back, but things are still not loading and running strange. I has suspicion it is a secret "easy" perms thing though since this is all after fooling around migrating sites somewhat.... 🤦 Any insights would helpful!
Thanks for the work on the script, and the comments everyone!
Addon: Oh yea, other issue I believe, is the .htaccess couldn't be accessed by litespeed... So setting chgrp on .htaccess to WS not good fro litespeed? Or I possible have wrong WS group... right?
# reset to safe defaults
chown -R ${WP_OWNER}:${WP_GROUP} $WP_ROOT;
chmod -R 644 $WP_ROOT;
chcon -R system_u:object_r:httpd_sys_content_t:s0 $WP_ROOT;
find ${WP_ROOT} -type d -exec chmod -R 755 {} ;
# allow wordpress to manage wp-content
chmod -R 664 $WP_ROOT/wp-content;
chcon -R system_u:object_r:httpd_sys_rw_content_t:s0 $WP_ROOT/wp-content;
find ${WP_ROOT}/wp-content -type d -exec chmod -R 775 {} ;
porthos-co, I really like your updated version, but I found an issue in two places. See the two bolded/italicized lines above. Under the headings "reset to safe defaults" and "allow wordpress to manage wp-content", you set the permissions on all files and directories recursively to 644 and 664, then you use find
to identify directories and change their permissions to 755 and 775. However, the -R
flag on the chmod command results in 755 and 775 being applied recursively, which includes all files. This overwrites the 644 and 664 permissions set two lines above.
If you remove the -R
flag from the chmod commands, the directories are correctly set to 755 and 775 while leaving the files at 644 and 664, which is what we want.
Updated code:
# reset to safe defaults
chown -R ${WP_OWNER}:${WP_GROUP} $WP_ROOT;
chmod -R 644 $WP_ROOT;
chcon -R system_u:object_r:httpd_sys_content_t:s0 $WP_ROOT;
find ${WP_ROOT} -type d -exec chmod 755 {} \; # REMOVED -R FROM THIS LINE
# allow wordpress to manage wp-content
chmod -R 664 $WP_ROOT/wp-content;
chcon -R system_u:object_r:httpd_sys_rw_content_t:s0 $WP_ROOT/wp-content;
find ${WP_ROOT}/wp-content -type d -exec chmod 775 {} \; # REMOVED -R FROM THIS LINE
Thanks to everyone for the various versions of this helpful script!
So, what is the final version of this? Someone forked it so that all improvements are included?
I have made a few additions:
I always set the groupname to that of the webserver (nginx/apache) which as far as I know is secure but let me know if you disagree
Added SE Linux context changes using chcon. Mine are standard Redhat / Centos contexts which you may need to alter
Speeded up the script by applying standard file permissions with chmod recursively (no find necessary) and then altering directory permissions using find and chmod as before for directories. Doing this means it executes 10-20x faster on large sites.
***** WARNING - I've only tested this on a couple of live sites so far with no issues it's been fine. Posting this in case it's useful but please do your own testing and be careful before using it in production or cronjobs. The original script by Michael is probably safer until this one has been tested more! **********