2

I have a server with several users and would like to allow some of them to store webpages on it. Thus, I have created subdirectories of /var/www for them and configured my webserver accordingly.

However, I do not want them to be able to view any contents of a subdirectory within /var/www other than their own. How can I do this? If I set the rights of the top directory to user:www-data and the access rights to 760, I think it would be possible. But how can I ensure that each file or directory created within their directory uses the same user:group attributes?

Also, I'd like to be able to use git to deploy web page contents. I don't want to know any technical details on how to do this, but rather how I should organize the rights again. I use gitolite and each repository is stored under /var/lib/gitolite/repositories (the owner of the files is the git user). What is the best way to allow the git user to write to one of the web page directories while using the correct user:group information? Is this possible at all? How do you manage your /var/www access rights? How do providers do it?

else
  • 123
  • 3
  • There's really no way to prevent people from seeing the contents of a directory that files are being served from -- the web server needs to be able to access those files, so the files/directories have to be either group- or world-readable... – voretaq7 Feb 11 '11 at 19:48

3 Answers3

4

First, note that your 760 would deny www-data group the permission to "enter" that directory, so it would be unable to serve files from it.

The +s bits on directories force files and subdirectories to be created with the same uid/gid as the directory itself (and subdirectories will also be +s), thus if you 

chown user:www-data /var/www/userdir
chmod 6770 /var/www/userdir

any files and folders created in that folder after that point will be user:www-data. Note that you only want to set this on the directories, and it will not "fix" files and directories that already exist.

If you don't need the directory listing or content negotiation features of the webserver, you can leave off the group r bit on the folder (6730). This will make it a little harder to write a script that gets run by the webserver and peeks into another user's directory (they'd have to know the name of the file they want to read). You can also mitigate this by using some form of suexec to make sure that scripts in user directories aren't run in the www-data group.

DerfK
  • 19,493
  • 2
  • 38
  • 54
1

Have a look at the Apache2 mod, mod_userdir for the standard approach for user Web directories.

gravyface
  • 13,957
  • 19
  • 68
  • 100
  • +1 -- There's already a canonical way that this is done. Unless you can articulate a reason mod_userdir & setting appropriate permissions/chroots on your users won't work I'd suggest sticking with that. See my comment on the main question too. – voretaq7 Feb 11 '11 at 19:48
  • I don't use Apache, but this sounds nice though. Thanks. – else Feb 11 '11 at 20:14
1

Regarding git access...

You permit the apache user to have read-only access to the appropriate git repositories. Then you periodically run git pull ... (e.g., via cron) to update the web server. This means that you don't need to worry about permissions on the filesystem at all -- all the files are owned by the Apache user; nobody else has write access.

This is important: the git user does not have write access to the Apache directories. The apache user is running a git pull operation and connecting to your git server over ssh (even if it happens to be running on the same host).

If you want to have the update happen automatically, rather than polling via cron, you can have a CGI script that triggers the git pull, and then in your repository post-update hook, you would put something like:

curl http://www.example.com/trigger-post-update-script
larsks
  • 43,623
  • 14
  • 121
  • 180
  • Awesome, I didn't even think of triggering a pull script. Thanks for that! – else Feb 11 '11 at 20:16
  • I do have one question though, what about security? Any best practice on how to protect the trigger? HTTP Auth? – else Feb 11 '11 at 20:42
  • How you protect the trigger depends a lot on your environment and requirements. If you make it available via https using basic auth you're probably in good shape. If the git server is on the same system as Apache, you can just restrict access to localhost. You could also get fancy with SSL...but I wouldn't bother, since the real impact of getting access to the trigger script is minimal, at best (it could turn into a DDOS, if someone hit it hundreds of times per second, but that's arguably true for just about any content you serve). – larsks Feb 11 '11 at 20:49
  • Last question: What about adding the git user to the www-data group? This way I could directly push using a trigger. Is that considered to be a bad idea? – else Feb 11 '11 at 22:15
  • I like restricting write access under /var/www to a single user, and I like the separation that allows me to host the git repository anywhere. – larsks Feb 12 '11 at 01:23