I think this is not too specific, in fact I think it's a very common problem. But I didn't find any threads giving a solution to the following.
I want to run website1 and website2 on a server.
Each virtual host has its own Document in /var/www/website1/web/ and /var/www/website2/web/
Permissions are set like this: rwx rwx r-x
Owner of both folders is: somedeveloperuser
Group of both folders is: www-data
I want PHP scripts in /var/www/website1/web/ to have write access to /var/www/website1/web/
EDITED:
What could be a good practice to forbid a script in /var/www/website1/web/ write access to /var/www/website2/web/ or any other folder grouped by www-data?
I am asking because I don't want any site, which could be in some way insecure to harm other website folders.
Thank you for reading and helping!
Related
I have a fresh, unmodified install of Apache on CentOS 7. I notice that when I look at the folder permissions for /var/www/html it and it's content is owned by apache. When a file is created, however, its owner and group is Apache.
Though html is owned by root:root, should all of the contents be owned by apache:apache? or [user]:apache with that user belonging to the Apache group? How should I go about this?
Edit:
Another question - do I want to change this? I do not have a very good understanding of file ownership in Linux systems but it seems with this configuration that the newly created files (apache:apache) are prevented from taking action against files that already exist (root:root). This should prevent PHP hacks from being able to manipulate any existing files, right? Is this just the illusion of security though?
Check your /etc/httpd/conf/httpd.conf file and search for user and group [e.g. User apache Group apache]. Those are the owners by default. In your website there is no need too add write permissions for files and folders assigned to user:group, but you can set readable by owner and others in order to be accessible via web.
Updated answer:
The main reason DirectoryRoot (/var/www/html) owned by root is security. You can leave root as owner of files and set group to apache. Regarding security you make sure apache group has read-only access to files [-> One first meassure]. The security is not an illusion. While files are owned by root and do not have rw access from others, it is hard for external attackers to gain write access to files [because this is the most common way to hijack a site].
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.
This might be a noob question, but can't find an answer anywhere.
I have a problem, which Another file permissions problem have helped me to ALMOST solve.
I have created a user in linux (danny) which has sudo access.
I have also created a new group which name ALSO is danny, and added the user danny to that group. This group has sudo (root) access.
I have all files and folders in my www folder owned by danny/danny group.
I have an image-upload code which is php. This code cannot upload images to a folder called "images" folder which is under the www folder, UNLESS I give the images folder 777 permissions.
So, I have followed the answer on the linked question, and have figured out that the user which the upload-script is run as is "www-data".
According to the answer on the link to the other question I posted, I need to add www-data to a group... But I am stuck here...
Which group should I add to? What should I do from here?
Any tips are appreciated.
Btw, here is some info about www-data and danny
id www-data:
uid=33(www-data) gid=33(www-data) groups=33(www-data)
id danny
uid=1000(danny) gid=33(www-data) groups=33(www-data)
Thanks and if you need more input, just let me know...
In general, NO, your content should not be owned by www-data. The only content which should be owned by www-data are the specific files that you need web applications to be able to modify and specific directories that they need to be able to create or delete files in. The rest should not be owned (or writable) by www-data because every file that www-data can write to is a file that an attacker who compromises your web server (including any scripts or web apps that it is running) will be able to replace with whatever malicious data he may choose.
It is especially important that www-data not own or be able to write to any executable file (e.g., scripts, flash files, documents in Word or other formats with macro capabilities, etc.) because replacing them with malicious executables would provide an easy way to attack users' computers or the web server itself.
I think it makes sense that files being used by www-data is owned by www-data. I mean who else should own it? The most important part is that the web app shouldn't have write access to its own web root. The reason why is becuase a directory traversal vulnerability in a PHP function like copy() or file_put_contents() might allow an attacker to drop a .php backdoor in your web root.
Another important attack to be aware of is that another process or user on the system might want to read or write to your web root, so its important that the very last number be a zero. The middle number is the group and your not using this, so it should be zero as well. The following 2 commands makes your web root readable and executable by apache, and only apache. Sometimes a different user account is used, so run a <?php system('whoami')?> to find out the correct user account.
chown www-data -R /path/to/webroot
chmod 500 -R /path/to/webroot
By the time the attacker has remote code execution to change the privileges of the web root its game over. The whole point is trying to foil the exploit from succeeding.
I'd add www-data user to group danny.
usermod -a -G danny www-data
This way www-data could enter danny's place, but not the opposite.
In order to allow www-data user to write to a danny group folder permission mask has to be like (where wildcard means any value is ok):
d???rwx???
Actually, your problem is that you need the user www-data to have write-access to the images folder.
And you probably want user danny to have full access to the folder as well.
EDIT: Additional word of warning:
having files writeable by your webserver is always a security risk. Be sure to check the files that are written, and make sure people can't upload or change code.
Summary:
* Don't let your webserver run scripts that are writeable, or in a writeable folder.
So make sure only the images/ folder is writeable, and doublecheck that everything that is written, is actually an image!
Either:
Set www-data as owner of the folder,
and chmod u+rwx www.
Set www-data
as part of a group X, and change the
owner of the folder to X, and chmod
g+rwx www.
Set the folder
world-writeable on your server (in
some cases, an acceptable solution
too, but less secure).
See an example here: http://mattpotts.com/portal/
I put an includeme.htm in each directory on the required path to find the point of failure. It works fine on my local machine (windows) with the same directory structure but fails on my remote (linux) server.
Directory structure:
+-firefli/ drwx--x--x
+-private_html/ drwx------
+-foo/ drwxr-xr-x
+-bar/ drwxr-xr-x
+-portal/ drwxr-wr-w
+-public_html/ drwxr-wr-w
+-foo/ drwxr-wr-w
+-portal/ drwxr-wr-w
The permissions confirm that it's the private_html directory causing the trouble. Hopefully you can see the purpose of the directory structure, I don't know if it's a common way of doing things but it works for me. Well, until now.
I've gone a very long way around asking it but my question is simply this: is there anything wrong with setting private_html to be drwxr-xr-x? Given that I do not want it to be accessible via the web. But the permissions shouldn't do that should they? Because it's apache making the public_html directory accessible via http.
You shouldn't need to block out web users with folder/file permissions on private_html, as it's outside the web root. As you say, web users can only get to stuff in public_html
For future debugging speed, if you have a relative web path you can convert it to a real path using realpath:
$path = realpath('../../private_html');
// $path is now /public_html/foo/private.html or whatever
Well, if you have set up your DocumentRoot correctly to point to public_html, it won't be accessible from the web, no matter what permissions you put on it.
The Private HTMl is not accessible from the web without you putting in a .htaccess file that would redirect it. If you don't know what that means/how to do that, you are safe.
You should be fine setting these permissions to whatever your script needs.
what are the user:group for private_html? The web server needs to be either a member of the group or the owner of the file. In order to read the directory contents the dirctory needs to have the execute permission for the webserver to open it. Essentially they should have the same user:group as public_html. You just want to disallow the write permission. tot he webserver. If you have set your document root to public_html private_html is not accessible via the web no matter what the permissions. Also, i always use realpath on the path arguments to and file operation.