Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm having problems dealing with Apache configuration: the problem is that I want to limit each user to his own docroot (so, a chroot() would be what I'm looking for), but:

  • Mod_chroot works only globally and not for each virtualhost: i have the users in a path like the following one /home/vhosts/xxxxx/domains/domain.tld/public_html (xxxxx is the user), and can't solve the problem chrooting /home/vhosts, because the users would still be allowed to see each other.
  • Using apache-mod-itk would slow down the websites too much, and I'm not sure if it would solve anything
  • Without using any of the previous two, I think the only thing left is avoiding symlinking, not allowing the users to link to something that doesn't belong to them.

So, I think I'm going to follow the third point but... how to efficiently avoid symlinking while still keeping mod_rewrite working?!
The php has already been chrooted with php-fpm, so my only concern is about Apache itself.

share|improve this question
Multilpe Apache instances, one per vhost (upgraded to actual host)? If they share an IP: behind a proxy, just on another port on localhost? THen it's even easy to run apache as the user itself. –  Wrikken Jun 26 '12 at 21:45
@Wrikken Yes, that would be a solution but however, would cost a lot of ram. That's why I was looking for another, viable, solution. Running more instances would be really interesting when having each user in his own "box" (like with OpenVZ)... but then I would sell VPSs and not shared hosting anymore! :P –  Alessio Periloso Jun 26 '12 at 21:48
@tubaguy50035 i am trying to install mod_security and setting the SecChrootDir inside the virtual hosts... will let you know what happens :) About the 404 (or... the "No input file." error), I've solved the problem using a proxy between apache and php-fpm. After trying to edit the php-fpm source code, I've realized it wasn't linear at all and I would lose too much time with it. So I wrote a proxy between Apache and php-fpm in python to change the variables with the ones that would be correct inside the chroot environment. If it would be useful, I've used the python flup library to do it :) –  Alessio Periloso Jun 26 '12 at 22:08
@Wrikken I've already fixed the problem about symlinking (I will add the solution as an answer here in a while), but it seems SecChrootDir does really works in every single virtualhost... so I could chroot every user to his own environment, avoiding VPSs. There are still some errors to be solved though: apache doesn't argues it can't be done, but says that there's no socket for fastcgi and probably some problems about the non-existant directories (obviously). Will let you know soom :) –  Alessio Periloso Jun 26 '12 at 22:12
@tubaguy50035 I think i've managed to secure apache enough using the SymLinksIfOwnerMatch option, also because the mod_security chroot seems to hang apache processes around (I have to kill them manually and I'm not sure what happens with a graceful restart). About the php-fpm solution, I can't dislose the source code because my company owns it, but anyway, using the flup library and using both the server and client classes can help you rewrite the variables, making fpm working. Just make sure to listen to a port mod_fastcgi can connect to, and to connect to php-fpm to make the proxy ;) –  Alessio Periloso Jun 27 '12 at 8:55

1 Answer 1

up vote 1 down vote accepted

Why do you need to restrict apache itself? Would it not be better/sufficient to lock your script runtime (php, Perl, ruby, ...) in a chroot? If so, look at mod_fastcgi and how to start a persistent interpreter for the particular language(s) you require.

share|improve this answer
I am already locking php into a chroot through php-fpm, and I'm thinking about a persistent interpreter for perl too... but having Apache users everywhere isn't going to make me sleep well :P However, I've added the "SymLinksIfOwnerMatch" option inside the virtual hosts declaration, and it seems to work pretty well, not allowing people to go outside the jail. But is it safe enough? –  Alessio Periloso Jun 27 '12 at 8:49
I'd think so. However, if you are prepared to "go the extra mile", look into Linux security enhancements, such as SELinux, GRSecurity, Tomoyo and so on. With those, you can limit the user's access on a more precise level (read about MAC and RBAC to get the drift). Also you can strengthen your chroot. –  ukautz Jun 27 '12 at 9:57
Oh, thank you very much for all these information... I've really appreciated them! :P Probably there would be some problems with GRSecurity and SELinux, since I am using OpenVZ containers, but in the meantime thank you for your useful advices! :P –  Alessio Periloso Jun 27 '12 at 16:14

Your Answer


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.