Is it possible to set permission for plugin directory to 554 because i am trying to set the permission for plugins directory and its files to 544 but its not loading the css and js files. same goes for themes .
General rule of thumb: Folders set to 755 or 750. Files set to 644 or 640. Important files (wp-config.php) should have more strict permissions like 600.
See more here.
I supposed the author was asking how to set file permissions to reinforce wordpress security. Instead of default 644, 755 by wordpress installation, he wants to try some custom permission values while still want wordpress work normally.
Here is the official codex page reference about recommended wp permmisions which may also take it as a reference cause no one has concrete widely tested sample yet:
http://codex.wordpress.org/Changing_File_Permissions
Furthermore,What i'd like to share with u is that
while i'm studying on changing the chmod via diff approaches, i found my mozila ftp user unable to change the chmod first bit value,
case1 : folder chmod value 755 in ftp view panel (such as the image below)
when you use full control ftp account (generated via cpanel)rightclick to view
attribute 755 and key in the value 644 then save.
the outcome is surprislying not 644, but 744 instead.
But in ssh command and cpanel file panel interface
will not have this kind of strange problem (1st bit didn't change)
in the chmod pemmsion settings.
In addition, I've also tried setting up apache passwd protection to certain folder as a way to enhance wordpress security, such as in the practice of adding .htaccess and .htapsswd to make wp-admin a password protected restricted directory, however, i found it not successful to implement on share-hosting server.
Below is another post discussing about wordpress security involving configuration of chmod and plugin compatibilities.
url: https://wordpress.stackexchange.com/questions/167900/evaluations-of-two-wordpress-security-plans-against-php-code-injection-attack/167905#167905
Thanks for this post and others' answer contributions :)
//2014 11 20
live testing of setting folder and file permission to 555 554 respectively and confirmed, the plugin folder and css js inside still working very well.
// firstly after testing, i found the permission can be set more strict than nromal ones mentioned in wordpress documentation link and still run normally.
all *.php file can be set to 544 to avoid writing permission or prevent injection
for normal folders usually 555 is okay,"wp-upload" folder needs a 755. if you set js, css to 544, you will get 404 error and of course they wouldn't be load, can set those folder to 555.
normally if you set the first bit to a stricter mode it's would not be able to use ftp software to modify, meaning if the file or folder has been set to 544, using ftp can not modify the chmod permission of the 1st bit. the complete modification should be using ssh or cpanel file management tools thus made the site files & folders more secure.
Related
You need to make this file writable before you can save your changes. See Changing File Permissions for more information
Make sure you've the correct permissions to edit the files in your FTP or File manager in Cpanel. You don't have any permissions to edit the required files. Let me explain what the File permission is and how to enable it.
What are file permissions?
This is a method of administering access rights to certain files of your site. There are 3 types of permissions, read, write, and execute. Each of these types can be defined per a certain user group. These include owner permissions, group permissions, and public permissions. Some host’s security settings do not have the ideal WordPress permissions set by default, you’ll have to add this yourself. You don’t need to worry about all these technical details. All you need to remember is the number: 666.
Changing file permissions in FTP
This is probably the quickest way of changing the file permissions for all of your template files in one swift command. Open up your favorite FTP client, navigate to your template directory (with style.css, index.php, etc.) and select all .php and .css files. Do not select images or subdirectories.
You can press CTRL + A to select them all, and click while holding CTRL to deselect items like images. After selecting the File Attributes option from the menu, you can change all the permissions to 666. You’ll notice the the group and public write permissions will automatically checked off.
After pressing OK all the permissions to the files you selected should be changed to -rw-rw-rw-. You should now be able to edit them via the theme editor.
Changing permissions in cPanel
You can also do this in cPanel, although not in bulk (for the version of cPanel I’m using anyway). Open up the file manager, navigate to the template directory (similar to FTP) and click on the file you want to change permissions for.
Change each one to 666, as before. This could be useful if you don’t have access to an FTP client, or just want to selectively make files writable.
You may see different sources telling you to set everything to 777, which gives everybody full permissions. I wouldn’t recommend this. Although it would work, it may open up security holes on your site. The 666 permissions are just enough for the text files you’ll be editing.
I have fixed this by a command :-
sudo chmod -R 777 "filepath"
I've moved my wordpress installation from a managed VPS to a new centos server.
Now I've a problem with writing to files directly from the wordpress admin panel.
Folders/files are set with 755/644. User owner is "wwwuser", group is "apache" (I use this one to access to the documentroot via ftp).
I think that the problem is that in /etc/httpd/conf/http.conf I've user and group setted both to "apache", in fact everything works if I change permissions to 775/664, which should mean that when the group owner is setted to apache everything work, right?
So my question is, should I change all permissions to 775 or there's another solution, which doesn't lead to security issues? Is it safe to make all folders and files 775 and 664? What if I change "apache" to "wwwuser" from /etc/httpd/conf/http.conf?
Edit: is it possible that the problem is that in phpinfo, environment pwd is set to /home/wwwuser/test and not to /home/wwwuser/?
I would advise to not change the user Apache is running under (to not edit the Apache config file) but to set apache as the owner of the files.
chown -R apache /path/to/your/app/files
I think it's the easiest solution. If you choose to change the permissions, you shouldn't have to change the permissions for everyone (other): you could change to 774 but I don't see why 775.
By default Apache is running under the apache user on CentOS.
This is a very common problem you are facing right now. Some times files/directories created/uploaded with FTP may have been assign a different users/usergroup. As #Céline Aussourd stated, if you have installed plugin from WordPress then all files and directories will get the default user/usergroup.
Now easiest way to identify which user should be assigned to your files is create a single test file using CPanel file manager called "test.php" and access it from web if it is working then check its user/usergroup and change all your setup files to that user/usergroup all together with
chown -R {user} /path/to/your/worpress/root
Replace {user} with apache web user.
UPDATE: (To install plugin without FTP details)
Please add following line to your wp-config.php after define('WP_DEBUG', false); line.
define('FS_METHOD', direct);
Remove plugin and re-install it, this time it wont ask you for FTP details and will write files directly.
For me, the solution was to add the mod_suexec apache module
I recently upgraded my Drupal core from 6.15 to 6.26. In the update process, I was asked to make a backup of all my files, then delete the entire Drupal installation from my server, and rebuild it using the supplied files. I then copied all relevant back-up files back to the server from my local machine. The problem I'm having now is that I get a "The directory is not writable" notification whenever I do any sort of action as an admin. Initially, I was getting the error that "sites/default/files" was not writable, but I fixed that, and I changed the permissions on every file in the installation to 755. Why am I getting this error, and how can I fix it?
Although permissions may be set to 755, most likely the directory ownership is set to the wrong user.
Just wanted to add this possibility, which fixed this issue for me after trying many things:
If you're running SELinux (like Fedora), you may have a "security context" issue on /sites/default or /sites/default/files. So even if you open it up using chmod 777 (not a good idea), you STILL get the permission issue.
the fix is (first cd to sites directory):
restorecon -rv default/
I ran this locally as root.
I don't pretend to be an expert on security contexts by any stretch, but Fedora documentation is here.
Hope that helps others avoid my headache!
After finding the permissions problem, you'll probably want to go back and chmod 644 for all files, and 755 for directories (besides the upload folder) just to be safe.
Drupal sometimes create some directories so check if sites/default/files sub directories have the right permissions
You can do it using two possible options:
1. change the owner of files directory and all files inside it to apache user
2. Give 777 permissions recursively to files directory
I am unable to upload themes to my WordPress installation via WordPress admin. I am getting the following error:
The uploaded file could not be moved to /home/debiprasad/webapps/wordpress/wp-content/uploads/2011/09
The permission of wp-contents directory and all sub directories are: 0755. Some people may suggest to make it 0777. This may work, but I don't think this is the correct solution. Because, all the folders should be have permission 0755 and this is secure. 0755 is the default and it works in other installations.
I want to know what's the reason of this error and what is the perfect and secure solution?
Assuming you use Apache, is your uploads folder owned by www-data? (or whatever user apache/php run as?)
If you have access to change ownership, 0755 should work as long as the upload folder (and subdirectories within) are owned by the same "user" that the web server runs as - so in most cases, that'll be www-data.
If this doesn't work, what method do you use to install themes? ftp, ftps or ssh2?
This has to do with media uploading in Wordpress.
Every time WP creates a folder for new uploads (it organizes uploads by year and month: yyyy/mm), it creates it with the "apache:apache' user and group, with full access to all (777 or drwxrwxrwx).
However, after that, WP cannot create a folder within that folder (e.g.: mkdir 2011 succeeds, but mkdir 2011/01 fails). Also, uploads cannot be moved into these newly created folders even though the permissions are 777 (rwxrwxrwx).
Once a month, I have to chown the newly created folders to be the same as user:group as the rest of the files. Once I do that, uploading works fine (which doesn't make sense to me The really frustrating part is that this problem doesn't exist in other WP installs on other domains on the same server.
* I wasn't sure if this should be here or on serverfault.
Edit: The containing directory /.../httpdocs/blog/wp-content/uploads has the correct ownership
drwxrwxrwx 5 myuser psaserv 4096 Jun 3 18:38 uploads
This is a Plesk/CentOS environment hosted by Media Temple (dv).
I've written the following test script to simulate the problem
<pre><?php
$d = "d" . mt_rand(100, 500);
var_dump(
get_current_user(),
$d,
mkdir($d),
chmod($d, 0777),
mkdir("$d/$d"),
chmod("$d/$d", 0777),
fileowner($d),
getmyuid()
);
The script always creates the first directory mkdir($d) successfully. On domain A, where the WP problem is, it cannot create the nested directory mkdir("$d/$d"). However, on domain B, both directories are successfully created.
I am running each script at /var/www/vhosts/domainA/httpdocs/tmp/t.php and /var/www/vhosts/domainB/httpdocs/tmp/t.php respectively I checked the permissions on tmp, httpdocs, and domain[AB] and they are the same for each path. The only thing that differs is the user.
A solution is to use FastCgi. This makes PHP run as the user who owns the site. New files and folders will be the same user and group. This will solve your problem.
There is a performance penalty to FastCgi but you get some added security as it restricts php. If you are hosting multiple website with multiple users this could be a good idea.
Try going to your miscellaneous settings page (or media depending on your version) and make sure the upload directory is still wp-content/uploads.
If you need to. set the full url too.
Also, as a final solution, disable the option to organize them into folders so that way WordPress doesn't even need to create folders.
Check for a setuid or setgid bit on a directory above the 2010 directory. ls -l will have an s or S in the permissions for the directory. Make sure this directory has the correct ownership.
Try to create directory recursive with mkdir($d, true)
<pre><?php
$d = "d" . mt_rand(100, 500);
var_dump(
array(
get_current_user(),
$d,
mkdir($d,true),
chmod($d, 0777),
mkdir("$d/$d", true),
chmod("$d/$d", 0777),
fileowner($d),
getmyuid()
)
);
I had a similar issue with Joomla recently, and solved the problem by adding myuser into the apache group, and add apache into the psaserv group.
One of our websites on a Media Temple DV was having this problem. Turning PHP Safe Mode off solved it. The directories were still created as apache:apache, but the media files were allowed in there.
One thing that occurred to me - WP will tell you that it can nto copy file to /wp-content/upload even when all permissions are right.... if
upload_max_filesize
in php.ini is too small (say 2M and you try to upload 3.5MB file)!
Hope that helps all thsoe who have right permissions but still can not upload!
You shouldn't need 777 on your directories, 775 at most should be sufficient. Just make sure it's set on the uploads directory with 755 for all the other directories above.
Also, you could try to chown it to www-data, sometimes that helps when your ftp user that you are logged in as when changing the permissions once a month doesn't have sufficient access level and owning the directories by that user prevents the server from being able to write into them.
Lastly, as someone has pointed out above, you may need to up the upload size limit along with making sure other file upload related php.ini settings are correct:
http://php.net/manual/en/ini.core.php
http://kb.mediatemple.net/questions/137/How+can+I+edit+the+php.ini+file%3F#dv
One common cause, often overlooked, is the disk quota, ie have you run out of disk space.