I have written a PHP script for file uploading and for testing I gave my upload directory 777 permissions. The script works fine.
Now I want to remove execute permissions for obvious reasons, but once I do that, I get the following error:
move_uploaded_file([filepath]) [function.move-uploaded-file]: failed to open stream: Permission denied
Just taking the permissions down from 777 to 776 causes this error to appear when I try to upload a file. I don't understand why having execute permissions should have anything to do with this - can someone PLEASE shed some light?
Thank you!
A directory must have execute permission to be accessible in Unix & Linux.
Quoting from here:
On a directory, the execute permission (also called the "search bit")
allows you to access files in the directory and enter it, with the cd
command, for example. However, note that although the execute bit lets
you enter the directory, you're not allowed to list its contents,
unless you also have the read permissions to that directory.
I agree with lserni that the fact that revoking execute permission on the directory for O (the third digit) causes the problem is worrisome as it indicates that the webserver is accessing the directory neither as owner nor as member of the group. You should fix that.
Just taking the permissions down from 777 to 776 causes this error to appear
This shouldn't happen. You ought to be able to run with 770 permissions, i.e., the directory should be owned by the Website user ID, with the group of web server.
This way the owner and the webserver are both able to manipulate the directory and the data. Ideally the Web server serving your website ought to assume the same user ID as the website owner, and that way you can keep the directory mode 700 and have it read-writeable and listable only by you.
If the last digit of the permissions is biting you, it means that the server is running with permissions for "everyone", which may be okay for a development site but isn't too good on a shared site (imagine your passwords being readable by any other website owner in the machine).
However, if you're running on a test machine, the 777 permissions are okay. Directory executable bit does not mean executable (a directory can't be executed anyway) but merely 'listable'. Without that bit, you can create and delete files but you can't know whether they're really there, and move_uploaded_files is objecting to this situation.
There are other solutions (e.g. chrooting each virtualhost in Apache); see also What are best practices for permissions on Apache-writable directories?
for removing the execute permissions you need to execute following commands..
chown -R nobody upload_directory
chmod -R 755 upload_directory
The first command changes the owner of your upload_directory and files under it to 'nobody' which is what php operates under. The second changes the upload_directory and files to only allow user access to writing. -R is for Recursive..
Related
What permissions do I need to set up on a directory in order to make it writable by php?
By "writable", I mean copying and creation of new files within that directory automatically by php itself.
I'm testing this on a free host, and the default permissions are 755.
When I try executing a php script, that attempts to create another subfolder of that directory, and copy certain files in it, and it fails.
If I set it up to 777, it works fine, but I assume that doesn't work on all Apache versions because of security reasons?
Also, when creating new files, does php act as the "owner"?
Whatever process that runs the PHP interpreter should should have a user account associated with it. Only that user needs write permission in the directory. So to answer your last question, it's usually www-data or apache that is the owner of that file.
Permission of 777 will work because it allows everyone to read, write and execute that directory but depending on your application this might be a security hole.
I'm using a Thumbnail plugin. It store thumbs in a folder on webroot.
but when it's trying to save the thumb, returns "no writable" error. it directory permission is 755.
If i change permission to 777, error disappears. but I read somewhere 777 permission can cause security issues..
What should I do?
you could change the owner (e.g. chown www-data:www-data your/direcotry/path in linux)
chown [OPTIONS] [Owner][:[Group]] FilenameOrFoldername
that the web-server user (the user who executes php scripts) owns the directory, then he has write access and you can leave the rights to 755.
7 5 5 = rwx r-x r-x
read write execute
first digit = owner
second digit = group
third digit = all other users
means that only the owner has write access (he can add files to the directory in this case the www-data user), the group (www-data) has read and execute rights and the rest has read and execute rights too, so there should not be a security risc with 755.
Here you have a tool where you can calculate the right -> chmod number conversion
the rights is written as owner/group/other, i think you can use 775 rights for your logic.
You could store it somewhere that the web server (like apache or nginx) can't access but your web app server (php, java servlet, whatever) can, and make logic for it to grab it from that folder and serve it up as an image. That way, you ensure that any files uploaded by users aren't ever executed.
It would cost more server resources, so that's something you should consider.
If the files are created by your app and there is no way for the user to directly modify them, then there is no problem with giving it write permissions.
This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Going crazy here, can't figure out why rename(), copy() functions don't work.
I get this error:
Warning: copy(/fullpathtofile/a4d3af69.jpeg) [function.copy]: failed to open stream: Permission denied in /var/www/vhosts/site.com/httpdocs/application/controllers/WorkController.php on line 31
Permissions are set to 775. It will only work with 777, but I don't think that's the right way to go for my social network site which is on my dedicated server, it's a safety issue right? Is that my only fix? I expected copy() should have worked.
The web server user does not have sufficient permissions to write to the directory you are copying to.
Walkthrough for solving your problem
chmod the "target" directory to 777.
Let your script write a file to that directory.
Inspect the written file (ls will do) and see which user owns it.
That is the user the web server process is running as.
Make sure your target directory is owned by that user (in which case chmod 755 will do) or that user's group (in which case chmod 775 will do).
Permissions of what are set to 775? If it is the target, you would need write-permission, otherwise you can't write to that location?
You need to set the ownership of your /fullpathtofile to the user who is running the webserver, and the same is true for the files within it. All files which are saved from PHP will be owned by that user. I am assuming you are saving an uploaded file to that directory: otherwise this holds for both the source and the destination.
If you're on dedicated, there is nothing wrong with 777 then.
You have to check perms and owner for the every nested directory involved.
ls -la them all.
chown the relevant directory to be owned by the user that the PHP script runs as (see get_current_user()).
Edit: This is wrong, see comments. The user you actually want to use with chown is the one the web service is running as. This is commonly nobody, apache, www-data, etc., and can usually be determined with ps aux | grep httpd.
I recently moved my website to a new host and now am experiencing some broken code..
I have an uploading script that is now returning this:
move_uploaded_file() failed to open
stream: Permission denied in *..
I've set the upload directory to 777 which worked fine, but my script is needed to have top level permissions..
(As the script itself sets permission to directories, does lots of copying etc)
Is there a way in apache I can set the PHP script to the owner of all the folders on my server?
Thanks
Also
When looking in phpInfo()
Under
apache2handler
User/Group nobody(99)/99
Is this related?
I wouldn't go that route, just give it permissions to the defined upload_tmp_dir, or define upload_tmp_dir to be a directory you have access to. If it is that directory you have problems with. If the target is the problem, and you've 777'ed it, something fishy is going on.
Do you have ssh access to your new host? The reason I ask is that it's probably not best to use the username/group as nobody, as most other services would use this too. I would change it to something like apache
You can then update httpd.conf, adding in these two lines (reloading the config after):
User apache
Group apache
Then, run chown apache:apache -R dir_name to make apache own it.
well,
When you are trying to set the permission like "0777", you must be running on same authority.
What I mean is.
For example, your script tells to change a folder/file permission to 0777, but the folder or file already has a permission and that is '0755' so you are not authorised to make that change. as the user have only 5 authority.
Either, you need to login to FTP and change the folder permission to 0777 and then you have full control over it or you have to stick with using 0755 or similar.
How should I handle image uploading using PHP?
How should I handle the chmod settings?
Example;
I have a dir called /image/ where i want to upload all my images.
Should I set this dir to chmod 777 and leave it like that? Or should i change chmod on that folder via PHP each time I need to upload a image. Is this correct, or should I be doing something else?
As thephpdeveloper mentioned, setting chmod once is enough. All subsequent writes into that directory will not change the directory permissions unless you explicitly chmod it to another permissions somewhere else.
The recommended permissions for directories on a *nix server is 755.
Setting permissions to 777 is not recommended. As mentioned by wic, it gives full permissions to everyone that have access to your server. Which makes it vulnerable if you are on shared hosting or sharing the server with other users.
Also to note is how PHP is run on your server. In fact, if you are running PHP as cgi, example suphp, permissions of 777 for directories are not allowed. Having 777 permissions on the directories your scripts reside in will not run and will instead cause a "500 internal server error" when attempting to execute them.
I recomend chmoding to 755
Only the user running the web server dameon needs permissions to the directory for writing. And you certainly don't want execute permissions on a directory users are uploading to.
Usually, folder settings are set once and that's it. It's rather pointless to keep setting the folder permissions to 777 via PHP, when you have already set it to 777.
No, you dont have to change the permissions on the directory each time. Once set, they are set so to speak.
Using 777 is overkill since it gives full permissions to everyone. Remove the 'x' bit and let apache (or whoever) own the directory. This makes it impossible to list files.