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.

  • 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, 2012 at 21:45
  • 1
    @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 Jun 26, 2012 at 21:48
  • 1
    @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 :) Jun 26, 2012 at 22:08
  • 1
    @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 :) Jun 26, 2012 at 22:12
  • 1
    @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 ;) Jun 27, 2012 at 8:55

2 Answers 2


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.

  • 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? Jun 27, 2012 at 8:49
  • 2
    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, 2012 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 Jun 27, 2012 at 16:14
  • I think "Why do you need to restrict apache itself?" is what people were saying until symlink attacks started happening in the wild where you could trick Apache into serving another user's database u/p from a PHP file as plaintext, and now it's "I hope we've restricted Apache enough" =).
    – sa289
    Jul 16, 2015 at 23:11

Anyone coming across this post would do well to note that Apache describes SymLinksIfOwnerMatch as not being a proper security measure:

This option should not be considered a security restriction, since symlink testing is subject to race conditions that make it circumventable."
(from http://httpd.apache.org/docs/2.2/mod/core.html#options).

Aside from just disallowing symlinks altogether and preventing users from overriding that setting in .htaccess files, to see a write-up of solutions out there for preventing symlink attacks, check out https://documentation.cpanel.net/display/EA/Symlink+Race+Condition+Protection (it's not just cPanel specific).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .