I have a CodeIgniter app running in production on Apache 2.2 with PHP 5.3 on Ubuntu 11.10. I am also running PHP5-APC, if that matters. So the app runs as www-data:www-data per the default Apache2 install.
I am trying to figure out what to set my file permission to. Many threads on SO seem to prefer 755 for directories and 644 for files. There is one directory that must allow files to be uploaded to it.
Currently my deployment script does something like this:
wipe old site
copy new site over
chmod -R 000 on the new site
chmod all directories to 500
chmod all files to 400
chmod 700 on the upload directory
Everything seems to work fine. I can upload files and so on.. so, I don't understand why people suggest 644 for files - I have a config file that has passwords and API keys - why would I want 'others' to have read-access to it?
What am I misunderstanding?
Well, mainly the 644 permission is meant for when you have /var/www/site1.com with different user and group set then www-data, because then the 644 would allow other groups and users to read from that file, but will allow to read and write the owner of the file.
As by default the user that uploads files and runs apache's processes is www-data then I honestly think that if it works for you and you have no issues, it's great because means a little more security.
Update
Just a small security issue, is that www-data has become a very common user and group for http services to run their processes. I would much recommend that each site/app have their own user and group.
*44 and *55 just means that the file/folder is readable by others.
This would be good if say, you uploaded files to the web server but they for some reason were owned by someone else (say your own login account), then apache could still read them and it'd be "no fuss". Or if you needed multiple groups to be able to access the files.
If you know you are uploading the files as the apache user, and apache (or whichever programs run under www-data) are all you need to be able to read/write the files, then *00 is completely fine. It can even be argued that it's a little more secure.
For people who don't know what they're doing on the linux command line, 644 and 755 are about the right mix between "convenient" and "safe" (completely debatable, though), so they are what is recommended for a quick fix.
When doing shared hosting, you have user accounts that upload php files via FTP. So, when user "joe" uploads his .php file, it is owned by "joe" and when Apache needs to read it to execute the script, it cannot. Users are usually in "users" group, so even giving privilege to the group would not be enough. That's why you need to give privilege to everyone, so that user "www-data" can read the file uploaded by "joe".
If you run your own server, than of course, you have full control and none of this matters.
Related
As the title suggests, I need the ability to create, move, and delete files and folders from php.
If I CHMOD all directories and files to 777, everything works great, but if I do 755 then the scripts die with errors about permissions.
From what I've read, using 777 permissions is insecure and should not be done. I have a VPS, but there are multiple users as I host a number of websites (some of which other people are in control of) and, regardless, I want to do whatever is the "best practice."
So, basically, what I'm wondering is how I should go about this? I'm new to php and "webmastering" and am not sure what to do.
Could anyone point me in the right direction?
One last note: In addition to being able to move and delete files that have been created from php, the scripts also need to move and delete files that have been uploaded via FTP from a Windows machine (I've noticed that by default when I upload files the CHMOD is 755).
EDIT: I it may be relevant for me to mention that I ran phpinfo() and found the following under the section "PHP Credits":
User/Group nobody(99)/99
Permissions are set for what the owner can do, what the owner's user group can do (the owner's peers in the same user group), and what everone else can do. That's what the 3 numbers are for: 753 is a "7" for the owner, a "5" for the group, and a "3" for everyone else. A "7" is full access (read, write, execute). A "5" is read and execute. You need write access to delete.
You should really read up on linux file permissions to see how they work.
I would recommend you use 775 or 770. The last digit is what anyone on the system or any shmoe browsing your site can do, so you want it as low as possible.
As far as your ftp script and your future other-users, just make sure they are in the same group as your apache user. Or, set up a group for those account you want to have access, and add your apache account to it.
In order to be able to manipulate files and directories without 0777 permissions, those files and directories need to be owned by the same user your PHP scripts run as.
You don't need to change things to 777, that gives the owner, group and guest all rights (read, write, execute). You can have it set to 755, or even 700 as long as the owner is whatever whatever the PHP process is running under. Typically this will be the Apache user, since the PHP script is running under the Apache process.
You don't need to give execute privs, but you need to give execute on the directories so that the process can do things like change directories (cd).
Nate, this relates to the basic 101s of UID and GID based access control. I am assuming that your "multiple uses" each have their own UIDs for FTP (and SSH?) access.
Typically files served by the webserver (Apache) must be read-accessible by the Apache child processes which will be running in www-data (or equiv) and hence must be o:r likewise any directories on the path to them must be o:e.
So you broadly have two options: (i) use a suEXEC / suPHP / FastCGI template to initiate PHP scripts in the UID of the owning directory, and (ii) run your scripts under mod_php5 and make any directories where you need script write-access owned by www-data.
This second approach is the most efficient in terms of machine resources, but it is terribly insecure as it in effect gives userA full R/W access to userB's resources and so on.
There's no way to square this circle. If you cannot guarantee shared trust between all users then you must read up on and implement a solution based on the (i) options.
Generally Folders should have 755 and files should have 644 permission set.
I'm facing this problem while working on PrestShop project.
Following PHP script solves my problem.
<?php
exec ("find /path/to/folder -type d -exec chmod 0755 {} +");
exec ("find /path/to/folder -type f -exec chmod 0644 {} +");
?>
I'm trying to use this Dagon Design PHP form to help a local non-profit publication enable their readers to submit photos. I've got the "mailer" part working -- the notifications work fine -- but the "saving a file to a folder" part isn't functioning.
On the form page, the author says "the directory must have write permissions," but I'm not sure "who" is writing to that folder -- is this PHP script considered "Owner" when it saves something on my site? Or do I need to allow save permissions for Owner, Group and Others?
I'm not sure why the script isn't saving the photos, but this seems like a good place to start. I've tried looking around on Stack for answers, but most questions seem to have to do with folder creation/permissions.
The page I'm clumsily trying to build is here, if that helps.
As Jon has said already, you don't want to allow write access to everyone.
It's also possible (depending on the hosting) that something like suEXEC is being employed - which will cause your PHP script to run as a user other than the webserver's (as reported by Dunhamzzz).
Probably your best approach, in my opinion, is a script calling whoami:
passthru('whoami');
Or alternatively you could try:
var_dump(posix_getpwuid(posix_geteuid()));
Bear in mind, this does give system information away to the world - so delete the script once you've used it!
Then, as you've correctly asserted in your question, it'll likely be the file permissions.
If you do have CLI access, you can update the permissions safely as so (first command gets the group)
id -n -g <username>
chmod 770 <directory>
chown <username>:<group> <directory>
(You may have to pre-pend "sudo" to the "chown" command above, or find other means to run it as "root"..., reply back if you get stuck.)
If you've not got access to run command-line, you'll presumably be doing this via a (S)FTP client or the alike. I'm afraid the options get a little to broad at that point, you'll have to figure it out (or reply back with the client you're using!)
As always, YMMV.
Finally, bear in mind if this is your own code, people will at some point try uploading PHP scripts (or worse). If that directory is accessible via a public URL ... you're opening the hugest of security holes! (.htaccess, or non-document root locations are your friend.)
If you are not sure how is your server configured (and this would influence who's the final file owner) then add write permission to anyone (chmod a+w folder), upload one file and ls -l to see the owner. Then you can adjust permissions to allow write access to certain users only
The PHP script that saves the files is running with the privileges of some user account on the server; the specific account depends on your OS and the web server configuration. On Linux and when PHP is running as an Apache module this user is the same user that Apache runs as.
Solving your problem reduces to determining which user account we are talking about and then ensuring that this user has permission to write to the save directory (either as owner or as a member of the group; giving write access to everyone is not the best idea).
You'll need to set the permissions of the directory to that of the webserver (probably Apache, nginx or similiar), as that's what is executing the PHP.
You can quickly find out the apache user with ps aux | grep apache, then you want to set the permssions of the upload directory to that user, something like this:
chown -R www-data:www-data images/uploads
So, basically the question is in the title and a little more detailed scenario:
I have a site's backend written in PHP (on linux server - centos 6) and I actually have only 2 users who have the access to it. They need to be able to upload images via some form. So, I made the simple upload script, but no matter what (or am to ignorant to know :/), the upload only works on folder permissions set to 777, so my question is is this ok, or should I implement some better 'common practice' in this situation?
You don't need the directory permissions at 777. What you need is to be certain the the directory is writable by the web server user, which either means making it owned by the web server user or owned by another user with its group set to the web server user and group-writable permissions.
So if your web server user was www-data for example (other common possibilities include apache, httpd, www):
# Set ownership to the web server user
chown www-data uploads_dir
# and make it writable by the web server user
# could also be 755 (readable by others)
chmod 700 uploads_dir
Or if it must stay owned by your account user (on a shared host for example), set the group to the web server user:
chown youruser:www-data uploads_dir
# and make it group-writable:
chmod 775 uploads_dir
The bottom line is that it is usually not a good idea to assign 777 (world-writable) permissions to a directory. Also, uploads_dir should ideally be placed outside the web server's document root so it isn't available vit HTTP requests.
You can also use something like suphp to run the php scripts as a user, while retaining the ability to have the folder not writeable by any other user or group.
You would need administrative access to your webserver for this, though.
A solution is to use FastCgi.
This make new files and directories owned by the the same user and group.
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.
Is it possible for hackers ( or other ) to upload/write a php file to a folder on my site that has chmod 777?
Example:
I have a folder that has chmod 777.
That folder contains images.
I use .htaccess to block indexing the folder.
Reformed question:
Can people write a .php file to my folder that has chmod 777 by using a PHP script on their website? For example , to list all the images in that folder
( I'm familiar with the right chmod for uploading folder etc .. , just asking it hypotheticaly )
Chances are very good that any legitimate user of that machine can write .php files, or anything else they want, to that wide-open directory. A 777 directory has almost no place on a shared host. (/tmp may sometimes be 1777, to set the sticky bit on the directory -- that allows only a file owner to delete a file in the directory. Normally, 777 means anyone can delete any file from the directory. But /tmp has definitely fallen out of favor on shared hosting environments because it is inherently unsafe.)
So: Are you the only user on the machine? Or is this machine shared with anyone else? Does this machine run any other services besides web server? If so, those other services might represent a possible attack vector as well.
Furthermore, if your permissions are set to 777 on your directory I wonder just how safe the PHP files you're running are -- I've seen many cases of people running insecure PHP scripts that allow an attacker to modify every HTML file on the entire web server, to infect people browsing the site. (Yes. Many. More than a handful by a lot.)
This is why whichever user account your web server runs as should not own any of the files of the website -- both static pages and dynamic pages. The web server should have only enough write privileges to write its access.log, error.log, and talk with a database server. Any additional privileges beyond this makes it far to easy for an otherwise benign bug in one of your scripts to become an exploitable vulnerability that allows your site to be used for attacking others.
777 is a bad idea. Fix that. Make sure your web server does not have write permission to any of the web content. Make sure no other service on the server has write permission to your web content. Make sure no other users on the server have write permission to your web content.
Update
This is easier than it sounds. Create a new webcontent user. If your web server already has a group of its own, lets use it and call it webgroup. If it doesn't yet, create a new webgroup as well. (adduser(8) and addgroup(8) if your VPS doesn't have its own mechanism.) Then set the owner for all your web content:
chown -R webcontent:webgroup /path/to/web/content
fix permissions:
find /path/to/web/content -type d -print0 | xargs -0 chmod 750
find /path/to/web/content -type f -print0 | xargs -0 chmod 640
then make sure your web server is using the Group webgroup directive to ensure that it can still read all the files it needs.
This will let your web server have read access to all your scripts and configuration, but if the web server itself is hacked, it can't modify any of it.
There are (at least) three ways someone can write to your directory:
If they have local control over the server (e.g. via a terminal)
If your webserver supports and allows the PUT HTTP method
If you have a script that allows people to upload files to that directory
As long as you do not publicly expose the folder in a writable way, no-one can modify the folder's contents remotely. This is regardless of local permissions. The local permissions you have set allow any local user of the server to read, write and execute in this folder - but this does not mean a remote attacker can.
Having said that, avoid 777 permissions unless absolutely necessary/safe.
If your code is on a shared server or a server with other services on it, it'd be possible for the other local users to write to your directory (if the other users are able to descend into the parent directories).
You'll need more than just a directory which is readable and writable by everyone (777) to get hacked. Using permissions 777 generally indicate a bad understanding of security features at all (or laziness when the code needs to be redistributed and the author does not want to make it too difficult by explaining file permissions to the user of the script).
I have checked out articles and tutorials.
I don't know what to do about the security of my picture upload-folder.
It is pictures for classifieds which should be uploaded to the folder.
This is what I want:
Anybody may upload images to the folder.
The images will be moved to another folder, by another php-code later on (automatic).
Only I may manually remove them, as well as another php file on the server which automatically empties the folder after x-days.
What should I do here?
The images are uploaded via a php-upload script.
This script checks to see if the extension of the file is actually a valid image-file.
When I try this:
chmod 755 images
the images wont be uploaded.
But like this it works:
chmod 777 images
But 777 is a security risk right?
Please give me detailed information...
The Q is, what to do to solve this problem, not info about what permissions there are etc etc...
Thanks
If you need more info let me know...
You have to make sure the upload folder is owned by apache or whoever user is as which the http server is started.
Alternatively you can use 775 owned by the UID who will be collecting the files and with as gid the group id as which the webserver is started.
There are of course variations on these themes.
As long as the webserver user or webserver group has permission to write in the folder, it will be fine for uploading.
There are all kind of cornercases, but then we'll need more info about your setup.
0 No Permissions (the user(s) cannot
do anything)
1 Execute Only (the user(s) can only
execute the file)
2 Write Only (the user(s) can only
write to the file)
3 Write and Execute Permissions
4 Read Only
5 Read and Execute Permissions
6 Read and Write Permissions
7 Read, Write and Execute Permissions
First number = OWNER
Second number = GROUP
Third number = OTHER USERS
One possibility for why it only works with 777 permissions might be if you are running SELinux. It's possible that it is preventing the write. I would have thought though that it would have prevented it even with the 777 permsissions but I'm no SELinux expert.
Every newbie mix users up. :)
You just have to distinguish OS user and website user.
The latter one has nothing to do with OS permissions.
For the OS users you have given 2 of them:
FTP user, owner of the files, uploaded via FTP
webserver user, owner of the files uploaded via browser.
Site user, who have no direct access to any files at all.
So, in case both these users are the same, you have no worry about.
But usually these are different users. So, one has no access to other's files unless directories has 777 and files 755.
That's why you have to set 777 for directories.
As we have learned above that website users has nothing to do with os permissions, you should not worry about security. 777 is ok.