Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I've had this issue on several setups, and I'm unsure of how to handle it.

At first, all of /var is owned by root:root. Clearly I don't want the web directory to be owned by root, so I do chown apache:apache /var/www. However, when someone is ssh'd in as root, if they do something like an svn update or edit a file, it's going to change the ownership back to root.

Is there any way to fix this? I've heard of using something with suPhp, but I'm unsure if it's necessary.

share|improve this question

2 Answers 2

up vote 6 down vote accepted

Note: In your case, the best would be to just drop root privileges for updates and run your scripts with your apache user:

 su apache -c "./update-script"

Otherwise, use chmod g+s /var/www. New files and sub-directories created inside this directory will share the same owner/group as the parent directory, by default. (This spreads recursively.)

According to the coreutils manual this is a GNU-ish extension which is not portable. This seems to work only for the group id, but I think it should be enough to deal with this general kind of issue. (Using umask 002 when running the script might help also.)

share|improve this answer
2  
+1 for the suggestion to drop privileges. –  rozcietrzewiacz Aug 14 '11 at 17:51
    
Yup! I've put it above the other stuff. –  Stéphane Gimenez Aug 14 '11 at 17:58
3  
Having a created file belong to the directory's group rather than the creating process's group is a BSD thing. Modern System V systems and Linux do it only if the directory is setgid. –  Gilles Aug 14 '11 at 18:09

Clearly I don't want the web directory to be owned by root

Why? What is your security model?

chown apache:apache /var/www

WTF is your security model!!!????

when someone is ssh'd in as root

Aaaarrggghhhh!

Stephane G's answer makes a lot of sense if you DO NOT USE the apache user. For most security models, a more sensible approach is to set up a group of users to have write access to the files and set the group ownership and group sticky, execute and write bit on directories, then allow the webserver uid access as 'other'. If you must have specific directories/files writeable by the webserver uid, then set the user on these to the webserver uid (but keep the same group as elsewhere).

And you should never allow root ssh logins (a AllowGroups/AllowUsers whitelist is far better than denying specific users/PermitRootLogin=no)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.