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:

  • anybody can read files in this folder (provided the file itself has the r permission on the user/group trying to read it, or for others)
  • anybody can create files in this folder (and optionally execute them, but only the ones created by this specific user)
  • anybody can delete files owned by other people in this folder (your files are not secured, whatever owner/permission they have)

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.

| improve this answer | |
  • How about "anybody can ALTER specific files in the folder". See the security problem there when the folder contains some executable downloads that people trust and install without posing any questions? :p – wimvds Apr 19 '11 at 13:08
  • @wimvds Nobody can alter files (delete only), they would need to be 0666 at least or owned by the folks who want to alter it. The 0777 permission of the folder is not inherited by files. – Capsule Apr 19 '11 at 13:17
  • Of course, the previous comment assumed that the files would be world-writable too (just in case you were wondering)... It just depends on the umask whether or not the default settings would lead to a security disaster or not. – wimvds Apr 19 '11 at 13:21
  • @wimvds I've edited my answer to make a clear difference between files and folders – Capsule Apr 19 '11 at 13:25
  • Tell me one thing, when I am creating a directory, using php, Will I be owner or group or user? – Starx Apr 19 '11 at 13:57

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.

| improve this answer | |
  • So, even a website visitor can delete the file with 0777 permission. – Starx Apr 19 '11 at 12:47
  • When I tried making a directory when the permissions to the folder was 0775, i couldn't. At least finally, I am being able to write on it using 0777. Tell me one thing, when I creating a directory, using php, I will be owner or group or user. – Starx Apr 19 '11 at 12:54
  • -1 How do you "execute" a folder? ;-) – Capsule Apr 19 '11 at 13:01
  • @Starx you could create the folder and set is owner to the apache process (usualy, 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. – Capsule Apr 19 '11 at 13:03
  • @Capsule: He means the files within the folder. – Anonymous Loozah Apr 19 '11 at 13:04

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 :)

| improve this answer | |
  • the parent folder doesn't need to be writeable (we are talking about a folder here, not a file). If it was true, then every folder in the full path would need to be writeable by the user running the apache process... – Capsule Apr 19 '11 at 12:45
  • well, I encountered a problem such that I couldn't transfer files from winscp to a linux system to a folder in /var/www/cgi-bin/ . So I had to make the www folder to be writeable! – Shrinath Apr 19 '11 at 12:50

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.

| improve this answer | |
  • YOu are right, But now I can write to the folder, but nothing except giving 0777, will allow me to do that. – Starx Apr 19 '11 at 13:56
  • In what regard was I right? The MAC implementation or the PHP based (open_basedir) restrictions? If it's the first, it could help if you specified your OS and the MAC implementation in use. – wimvds Apr 19 '11 at 14:32
  • You are right, in the regard of what you have assumed. – Starx Apr 20 '11 at 3:21
  • Well, if the owner of the folder is set correctly (preferrably to the user/group that is used to run apache/php) then even 700 (or 770 - depending on the setup) should suffice. So it all depends on the configuration of apache/php, and you will have better luck posting this (with all relevant details regarding your configuration) on ServerFault... – wimvds Apr 20 '11 at 7:22

Your Answer

