views:

63

answers:

4

This might be a noob question, but can't find an answer anywhere.

I have a problem, which http://stackoverflow.com/questions/3483832/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...

A: 

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:

  1. Set www-data as owner of the folder, and chmod u+rwx www.
  2. Set www-data as part of a group X, and change the owner of the folder to X, and chmod g+rwx www.
  3. Set the folder world-writeable on your server (in some cases, an acceptable solution too, but less secure).
Konerak
Finally got it to work, I followed solution 1 you proposed above. One last thing, the permissions are now 765 on the image_folder. This is good and safe I hope? BUT, how can I restrict people from viewing my file in the browsers? (what I mean is, for instance, you type www.domain.com/images, then all folders show up)
Camran
@Camran: To prevent apache from showing directory listings, use .htaccess to turn off the "Indexes" Option. (`Options -Indexes`)
Dave Sherohman
-1 a web app should not have write access to its own web root, and under no condition should the folder be world writable or readable. This is massive mistake and it really bothers me.
Rook
760 permissions better (though danny won't be able to access that folder).The .htaccess idea is good too.
LatinSuD
@LatinSuD I think even that is too loose, read my post I explain why
Rook
World readable is rarely an issue, other than for files which contain things like database passwords. Ditto for executable. (You're already letting random users on the internet execute the code via their browsers...) With respect to web-accessible/web-executable files, write access is the only thing that normally needs to be restricted. 644 or 755 is usually the way to go.
Dave Sherohman
@Dave Sherohman I strongly disagree, if another process (like mysql's `load_file()`) or another user can read your php config to obtain a clear text username/password, a read .htacess password. Hacked :).
Rook
@The Rook: You're disagreeing with something I didn't say. To quote myself: "World readable is rarely an issue, **other than for files which contain things like database passwords**." The php/.htaccess files you mention are clearly such files and should, therefore, not be world-readable according to my earlier comment.
Dave Sherohman
He's disagreeing with something I didn't say either ;) Let me edit the response a bit to add a word of warning to the quick-and-dirty readers.
Konerak
@Konerak Don't give anyone anything, setting the web root as world writable is serious mistake, my -1 stays. chmod 500 or 550, no one should have write access, its not needed unless you need a folder for cache or upload.
Rook
@Dave Sherohman Your right, i was lazy and i didn't read your entire post. You have a good post, you know what you are doing.
Rook
+1  A: 

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???
LatinSuD
Any thoughts on the comment I posted on Koneraks question?
Camran
+2  A: 

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.

Dave Sherohman
A: 

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.

Rook
Do note that, if www-data owns the files/directories, then making it unwritable is a minor speedbump which may stop some canned attacks, but not much more. Why? Because the file's owner can change its permissions, so, if www-data owns the file, an attacker can easily give himself write access. If not, the attacker can't gain write access without first going from "web exploit" to "root exploit" (at which point it really is game over, regardless of permissions on the web root).
Dave Sherohman