i have read many tutorials about file permissions but all they say is for example "if you don't want others to write to your files, set it to xxx..."
but in a web host, who is who really?
there is just a web server (apache) and php and mysql and other programs. there is no "other users". the tutorials said that apache is considered "public". but i have a php scripts wich gets an uploaded file and puts it in "downloads" directory. i set that directory's permission to 744. it means group and public should only be able to "read" and owner has full access.
i expected my uploaded file not to be transfered to that directory because of no "write" permission for "public". but the file was there. and more confusing for me was when i tried to download the file, i got a "forbidden" error. i expected to be able to download the file because the public had the "read" permission.
The user this case is the web server itself. Apache is usually running as the user "apache" or "www-data" when it reads and writes files to the server filesystem. Static content should be readable by the server. Upload locations must be writable. Depending on the other users on the system you may consider the web server to be the "other" user and the webmaster account the actual file owner.
Related
I've been doing web development for about 6 months now for fun and so I never really had a reason to be secure. Now I want to change that but I'm having a hard time understanding apache file permissions. I created the server and usually just ran var/www with 777 permissions because I needed to get by and didn't have information worth stealing. I researched user permissions and now I have run into a problem after configuring some things. I added the apache user "nobody" to a group I created called webserver, I also have an ftp user in this group. I set var/www permissions so that "me" and the group webserver have full permissions on for the folder and enclosed files and other users have no rights (can't read). When I attempt to view my sample website on 'localhost' I get a permission denied message from apache, but apache has full ownership of the file so why can't it process the file, send the appropriate response the the computer which requested it, and complete the transaction? Does Apache process http requests as a different user? I'm confused.
Usually on Ubuntu, apache run with the user www-data.
You can also pimp it by editing APACHE_RUN_USER and APACHE_RUN_GROUP in the envvars file.
I installed mediawiki on a webserver to some folder
drwxr-xr-x /server/web/mediawiki
This directory contains a file LocalSettings.php. Initially this file contained DataBase settings (user/password) as plain text.
Following the guide
https://www.mediawiki.org/wiki/Manual:Securing_database_passwords
1 I tried to read protect LocalSettings.php with chmod
-rwx------ LocalSettings.php
and got an error when tried to reload mediawiki page in web-browser
failed to open stream: Permission denied in .../includes/WebStart.php
So I had to give reading access to LocalSettings.php to proceed
-rwx---r-- LocalSettings.php
So, easy way didn't work for me for some reason.
Question 1: if you know why easy way didn't work, please, explain me.
2 Than I followed the other way described in the guide. I cut all the DataBase settings (user/password) from the LocalSettings.php to an external file (DBpsw.php) that I placed outside of the web accessible folder:
drwxr-xr-x /home/mediawikiDBpsw/
-rw-r--r-- /home/mediawikiDBpsw/DBpsw.php
and included /home/mediawikiDBpsw/DBpsw.php to the /server/web/mediawiki/LocalSettings.php
But as you can see, the folders /server/web/mediawiki, /home/mediawikiDBpsw/ and the files /home/mediawikiDBpsw/DBpsw.php , /server/web/mediawiki/LocalSettings.php are accessible to others (readable). Thus anyone "other" who has access to the server can ssh to the folder /server/web/mediawiki read the file LocalSettings.php, learn the path /home/mediawikiDBpsw/DBpsw.php from there and read the DataBase settings (user/password) from /home/mediawikiDBpsw/DBpsw.php.
Question 2: How can I protect DataBase settings (user/password) from the "other" users that have access to the server?
Thank you in advance!
The group of the file /home/mediawikiDBpsw/DBpsw.php with DataBase settings should be changed to the webserver's user group (use chgrp).
Than rights of the file should be changed to (use chmod)
w-rw-r----- /home/mediawikiDBpsw/DBpsw.php
Now, mediawiki will run, because webserver's user will have access to the DataBase settings. Still DataBase settings will be safe as others will not have reading access to /home/mediawikiDBpsw/DBpsw.php (unless they are in the same group as webserver's user, which shouldn't be the case).
An .htaccess file is uploaded to a directory via ftp, the owner and group of the said file is then generally the ftp user and / or root.
If the said directory had file permissions set to 0777 would it at all be possible for a remote script to write over the said .htaccess file, or would every attempt always be blocked as the owner and group of the .htaccess file is the ftp user (and the root), and the hacker (depending on which port they were attempting to enter through) will not be logged into the server as the ftp user (and hopefully not the root user either).
The reason I ask is because I have the need for a directory to be permissions 0777 and am concerned that the .htaccess file (which prevents scripts from running in the said directory) could simply be overwritten meaning the said server would be vunerable to attack.
Thanks,
John
Personally, I wouldn't set 0777 permissions on a directly containing a .htaccess file. In that situation I would probably advise moving the files requiring 0777 permissions into a sub directory.
You're going to be vulnerable to an attack if a script has write access to that folder regardless. Here's an example from a true story on a friend's server:
Old version of TimThumb allowed files to be uploaded maliciously
The file uploaded was Syrian Shell, a script used to decrypt user permissions and begin creating new files
Access was given to the intruder and the server was effectively turned into a host for a phishing site.
I highly recommend you take a look at your structure. Move write access to a subdirectory. Hope this helps.
Hi suppose my site as www.xyz.com and i have a folder as _Userfile which have file uploaded by my users and if they download there file the link is www.xyz/_Userfile/userfile.doc now i want to learn this:
if some one has the link to other user file he can download it i want to solve this(privacy)
2: protect my site file from website downloader.
ASAP plz
Also i am using virtual directory to save my user files so i need a way to protect any type of file to be downloaded by any kind of software
You'll have to implement an authentication mechanism, and to serve those files through a server-side application (in PHP, Java or whatever), that checks if the authenticated user has the right to access a resource, then reads the resource from the disk and writes it to the HTTP response. The documents should be placed in a location that is not directly accessible through HTTP.
Just add index.html file in the folder _Userfile... This will prevent others accessing the whole directory listing in _UserFile folder! Simple isn't it?
Today I moved my website to a new hosting company (Verio). I've done this lots of times before, and I know that your website should go inside the "htdocs" folder.
Now usually when I use FileZilla, I can do a "Right Click" on a filename to get the URL of that file. This is the result of my root default file: ftp://test#test.com/www/htdocs/Research/index.php
However, on the web, the true URL of my default file is: www.test.com/Research/index.php
My index.php file is in the website root folder. Does anyone know why FileZilla would include the server folders "www/htdocs" as part of the URL? These folders should not normally be visible to the user.
OR, is this look correct?
That ftp url is correct. Your FTP account has access to the two folders (www/htdocs/) before the document root, as most hosting providers provide.
You are also correct to assume that http access is limited to the document root. (Meaning they cannot see www/htdocs/)