Currently, I am not being able to upload a file to a web folder. Whatever I do, even setting the folder permissions to 0777 I cannot upload the file to it. Out of curiosity, I searched for the risk associated while setting the file permissions as 0777.
Found a question here, but didn't quite had the answer what I was searching for.
I am completely unaware in this subject. What are the risks associated?
Setting 0777 on a folder (and I'm talking about a folder here, not a file) doesn't involve any execution security risk like some would state.
Execute is needed on a directory to access the inode information of the files within. You need this to search a directory to read the inodes of the files within. For this reason the execute permission on a directory is often called search permission instead.
See http://content.hccfl.edu/pollock/aunix1/filepermissions.htm
The risks are:
r permission on the user/group trying to read it, or for others)If you want to secure some files, you have to create another folder with "normal" permissions (rw for you only, or rw for you and your group) and put your files in it.
On the other hand, nobody could turn a non-executable file into an executable one (chmod are not permitted if you don't own the file).
What the risks are not?
Some people think 0777 is inherited by every file in the folder. This is wrong. You can't edit a file if you don't have the w permission just because its parent folder is 0777. You can't read a file if it doesn't have the r permission.
How to secure it?
If you have access to some shell or if your FTP client allows you to change the owner of the files and you know which owner you need, then you could create the folder and set its owner to the apache process (usually, nobody, daemon or apache) and just set 0700 permissions. Problem is, other users, like you when browsing using your FTP client, won't be able to read the files created later by PHP, which is not necessarily an issue.
OK but what about files?
I'm not talking about risks inherent to files execution because there's no reason you would want to force the x permission on a file that shouldn't be executed in the first place.
If some web app needs to write in an existing file, setting it to 0666 (or 0600 if the owner is the apache user) is enough.
Everyone who has access to the folder (i.e. the x permission on every folder in the path) can read, modify and execute the file.
If it's something that's actually executable there is a high risk of a malicious users adding bad code and then waiting for you to execute it to make you execute some evil code (like creating a copy of bash that is set to setuid and executable by the attacker).
If you are on shared hosting, check if 0770 isn't sufficient - if your FTP user is in the same group as the webserver it will be sufficient. In that case the above-mentiones risks usually do not apply since you are never going to execute stuff in an upload target folder and PHP has open_basedir to restrict other users from accessing your files. However, if the host also supports CGI scripting (e.g. using Perl) that can be easily circumvented.
owner or group or user.
nobody, daemon or apache) and just set 0700 permissions. Problem is, other users, like you when browsing using your FTP client, won't be able to read the files created by PHP.
I am probably not answering your question regarding the risks, but I can guess why you can't write.
Probably the parent folder doesn't have write access for that user...
use something in line of chmod ugo+w whateverfile to the parent folder recursively until you can create files in it :)
/var/www/cgi-bin/ . So I had to make the www folder to be writeable!
Assuming you've already ruled out some basic PHP security settings (open_basedir restrictions et al) - debugging and error_reporting(E_ALL); (make sure you log errors instead of displaying them on production systems) are quite useful to check this :p.
If you set the folder permissions to 777 (world-writable) and a process still can't write to that folder then there could be a MAC implementation running that prevents just that sort of thing (SELinux or AppArmor are likely candidates if you're using Linux). If that's the case then changing the policies they impose will help solving this issue. Setting a folder world-writable is a possible security issue (especially when the folder in question is exposed to the outside world), and also can most likely be avoided.
