hackermom

Alias does not change the root dir, according to Nginx documentation. This was what made us believe that through eventual exploit, it could be possible to reach the active root dir through a completely different path as set per alias. In addition to that, having an erroneous document root communicated to CGI components such as PHP or mod_perl can lead to problems. We're still following Nginx development, in case things evolve.

We used something just like that to map users' home directories, but it doesn't solve the problem of not being able to set a unique root directory for each user case. Nginx accepts just one root dir setting, and it can't be conditionally set (or overwritten in a later if-else scenario) by putting it inside a location clause. One solution is to globally set /home as the definite root for all user location cases, but this does not sit alright with me - the document root should just not sit outside the target's home.

I wasn't aware that this was a Q&A or issues tracker for Nginx, which is why I never had the intent of bringing details up. My apologies for posting these things in the official Nginx resources. The sarcasm is on the house.

One problem that comes to mind is Nginx' inability to have multiple root dirs set for one and the same host depending on what location directive will be in use, for example when wanting to set unique root dirs during userdir mapping - which also happens to be something that Nginx can't do as properly as Apache. Another problem I can recall is how some configuration scenarios require an abundance of PCRE matching clauses to fulfill, which in turn causes Nginx a tangible but most noticable delay for each request that happens to match the implied regexp portion. I am not sure why this is the case, and I am not sure why it isn't so in Apache, where regexp clauses introduce no noticable stall.