Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

That said, symlinks aren't necessarily bad but you have to have a clear understanding of your implementation of Apache. To a non-chrooted Apache, symlinks certainly pose a significant risk to exposing files outside of your document root.

I got this from an old thread that's been answered already. I was wondering how can system links expose other files outsides the document root? I thought they only point to one directory. Would I not have to specifically add the symbolic link myself to allow a hacker to get out of the document root? Also how does a chroot help in this instance

share|improve this question
On an unrelated note, you should accept some of your older questions some of which were answered for quite some time. – Holger Just Mar 8 '11 at 11:30
up vote 6 down vote accepted

Often, you run actual web applications inside your webserver (php, perl, whatever). This web-apps typically have write-access to some directory inside the document root to upload stuff.

Now, there might be a bug inside your web-app which would allow an attacker to create arbitrary files inside your web-root (and then probably symlinks too). This might even be possible when you don't have an actual upload component, but just the bug. These bugs are not that uncommon that you should ignore them. Especially applications like wordpress have a rather long history of this kind of bugs.

Now that an attacker can create files and symlinks inside your web root, it can let those symlinks point to arbitrary files on your webserver (/etc/passwd, config files with clear text passwords, ...) which finally could mean that an attacker can download all these files and use the gathered information for further attacks, like dictionary attacks on SSH password, simple authorized access to your database, ...)

If you restrict your Apache to not follow symlinks, this attack vector is much harder to exploit. Another, equally important security measure is to restrict read-access to only absolutely necessary files for the webserver / web application user. You could also use external application server (common with python and ruby applications, but also with fcgi setups) and run this with another user than the core webserver user. If you restrict access to important files between this user and the webserver user, you can gain a rather high security level.

Another alternative would be to chroot your apache to the document root, in which case the operating system would ensure that the Apache processes can access no files outside the document root. Note that this is rather hard to achieve with the packages in common distributions.

share|improve this answer
Thanks for your slightly more detailed answer!! – user20338 Mar 10 '11 at 22:58
Disabling symlinks can break some popular modules like mod_rewrite! – Dragos Oct 6 '11 at 7:59
mod_rewrite is perfectly capable of doing its work without allowing to follow symlinks. – Holger Just Oct 7 '11 at 8:21
If an attacker can create arbitrary files including symlinks he/she probably can create php scripts. Does this mean we should avoid enabling php? Enabling FollowSymlink is not a security risk on its own, just like any other feature that can be dangerous when exposed to attackers! – Semra Apr 21 at 16:29

Let's say I manage to get into your server, but I know that you'll close the loophole soon (perhaps it's an RSA tokenised password that changes every 60 seconds and I happen to have the password for the next 30 seconds). Or I only have 30 seconds to deploy my back door into your server, because you've left your terminal open and I know you'll be back soon and I'm an oppertunist.

The quickest and easiest thing for me to do would be to symlink / to say htdocs/mysuperhiddendirectory/ and now I can browse your entire file system remotely.

If you are running apache as chroot then symlinking / will only link to that process's root, not the actual OS root.

share|improve this answer

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.