# Equivalent of Apache's SetEnv Variable **URL:** \ **Category:** NGINX\ **Created:** [July 29, 2010, 6:19pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407 "2010-07-29T18:19:08Z")\ **Posts on this page:** 20\ **Page:** 2
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 9:17am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/21 "2010-08-05T09:17:54Z")
On Å›ro, sie 04, 2010 at 02:48:07 -0700, Michael S. wrote: > might be an interesting approach, haven’t tried it yet. would this add > an additional stat call or two though for every PHP request, Igor? While we’re at it, I had an experimental patch some time ago that provided location mapping based on file extensions instead of URIs which would prevent the above exploit. The config looked like: types { # … application/x-httpd-php php; } location / { root /the/document/root; } location @application/x-httpd-php { fastcgi\_pass …; # etc. } It never went to production but I guess I could refresh and post it if there’s some interest in it and it has a chance of being accepted upstream (guarded with some config option, of course). Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 9:30am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/22 "2010-08-05T09:30:47Z")
On Thu, Aug 05, 2010 at 09:17:17AM +0200, Grzegorz N. wrote: > > > > # … > > It never went to production but I guess I could refresh and post it if > there’s some interest in it and it has a chance of being accepted > upstream (guarded with some config option, of course). How may this prevent from the exploit if a requested file is “/dir/1.gif/2.php” ? As I understand the file will have “application/x-httpd-php” type ? – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 9:27am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/23 "2010-08-05T09:27:16Z")
On Thu, Aug 05, 2010 at 12:01:38AM -0700, Michael S. wrote: > Yeah I expect nginx to only be aware of the filesystem it has access to. So open\_file\_cache saves stat calls? How do you invalidate the cache if a file is removed? Or if I put a new file that wasn’t there I want it to instantly show up not 404 for a while? Apologies if you’ve covered this already. open file cache entries are valid for open\_file\_cache\_valid time, 60s by default. If you want to cache file errors such as “not found”, you may set open\_file\_cache\_errors on. > > > > a gaping potential issue to upload arbitrary files named xx.php and you are > > > > exploit [http://site.ru/images/as5df3.jpeg/.php](http://site.ru/images/as5df3.jpeg/.php) > > > > Igor S. > > > > [mailman.nginx.org archive](http://nginx.org/mailman/listinfo/nginx) > > > > – > > > > Igor S. > > > > [Igor Sysoev](http://sysoev.ru/en/) ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 10:07am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/24 "2010-08-05T10:07:05Z")
On Thu, Aug 05, 2010 at 11:29:55AM +0400, Igor S. wrote: > How may this prevent from the exploit if a requested file is > “/dir/1.gif/2.php” ? As I understand the file will have > “application/x-httpd-php” type ? The patch hooks into the static module ngx\_http\_static\_handler, takes r-\>headers\_out.content\_type and searches for an appropriately named location. If found, it reroutes the request there. Like I said, the patch has never seen production use. Also, security wasn’t really the motivation so I may be badly mistaken about it. Hmm, getting more and more uncertain about it 😉 In the example above, is 1.gif a file (and /2.php the path\_info), or is it a directory (and 2.php is a normal file)? -ENOCOFFEE, I guess. Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 9:36am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/25 "2010-08-05T09:36:03Z")
On Thu, Aug 5, 2010 at 12:17 AM, Grzegorz N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > location @application/x-httpd-php { > Â fastcgi\_pass …; # etc. > } I think this would be more appropriate, personally: type application/x-httpd-php { fastcgi\_pass …; # etc. } it’s not really a location, and needing to use the “@” for prefixing a named location… all that seems like a hack bolted on to the existing framework. it’d be nice to see type text/plain { expires max; } type text/css { expires max; } … etc … currently the same thing is a location block with js|css|ico|gif|jpg|jpeg etc… one single line to max the headers would be interesting to fill in. and not have it be conflicting with existing locations. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 10:10am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/26 "2010-08-05T10:10:01Z")
On Thu, Aug 05, 2010 at 10:06:08AM +0200, Grzegorz N. wrote: > wasn’t really the motivation so I may be badly mistaken about it. > > Hmm, getting more and more uncertain about it 😉 In the example above, > is 1.gif a file (and /2.php the path\_info), or is it a directory (and > 2.php is a normal file)? -ENOCOFFEE, I guess. What’s about when “/dir/1.gif/2.php” is proxied to remote server ? nginx has no access to a filesystem of the file. – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 10:12am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/27 "2010-08-05T10:12:21Z")
On Thu, Aug 05, 2010 at 12:09:33PM +0400, Igor S. wrote: > What’s about when “/dir/1.gif/2.php” is proxied to remote server ? > nginx has no access to a filesystem of the file. It doesn’t go via the static module then and the patch won’t do anything. Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 10:11am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/28 "2010-08-05T10:11:11Z")
On Thu, Aug 05, 2010 at 12:35:13AM -0700, Michael S. wrote: > I think this would be more appropriate, personally: > > type application/x-httpd-php { > fastcgi\_pass …; # etc. > } > > it’s not really a location, and needing to use the “@” for prefixing a > named location… all that seems like a hack bolted on to the existing > framework. Sure it is, it was the simplest thing that could possibly work. An upstream submission would have to be much cleaner, of course. > … etc … > > currently the same thing is a location block with > js|css|ico|gif|jpg|jpeg etc… one single line to max the headers > would be interesting to fill in. and not have it be conflicting with > existing locations. I like your proposed syntax much better, actually. Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 10:12am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/29 "2010-08-05T10:12:56Z")
On Thu, Aug 5, 2010 at 1:10 AM, Grzegorz N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > I like your proposed syntax much better, actually. Of course 🙂 I’m a smart guy! It’s sort of a meta/fake location, so a location block doesn’t make sense. It maps to types, so a “type” keyword makes sense 🙂 ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 10:19am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/30 "2010-08-05T10:19:58Z")
On Thu, Aug 05, 2010 at 10:11:29AM +0200, Grzegorz N. wrote: > On Thu, Aug 05, 2010 at 12:09:33PM +0400, Igor S. wrote: > > > What’s about when “/dir/1.gif/2.php” is proxied to remote server ? > > nginx has no access to a filesystem of the file. > > It doesn’t go via the static module then and the patch won’t do > anything. The issue is that someone is able to upload a image file to a directory with scripts (I do not know why he is not able to override some valid images or even the scripts themself in this case). Then someone requests the image file as “/dir/1.gif/2.php” making exploit. I do not see how using types will help in a case when nginx ahs not access to remote filesystem. – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 10:50am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/31 "2010-08-05T10:50:25Z")
On Thu, Aug 05, 2010 at 12:19:22PM +0400, Igor S. wrote: > The issue is that someone is able to upload a image file to a directory > with scripts (I do not know why he is not able to override some valid > images or even the scripts themself in this case). Then someone requests I guess it comes from apache-land, where the simplest config is “run all .php files via the interpreter” (compared to nginx’s “run all files under this directory via the interpreter”). The directory where the user is able to upload files is often a subdirectory of the application, as in: /index.php /foo.php /uploads /1.gif /2.png /images /foo.gif The more naive apps simply allow uploading of everything and store that under /uploads, while the smarter ones try to filter files for validity. So you cannot overwrite /foo.php or /images/foo.gif (barring directory traversal bugs…) but can upload /uploads/anythingyoulike.gif > the image file as “/dir/1.gif/2.php” making exploit. I do not see > how using types will help in a case when nginx ahs not access to remote > filesystem. It won’t help at all in that case. The proposed types would be a feature of the static module. It wouldn’t be useful in single-huge-site deployments, only for sites running on a single server (Nginx+PHP). Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 11:13am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/32 "2010-08-05T11:13:15Z")
Thu, Aug 5, 2010 at 1:49 AM, Grzegorz N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > It won’t help at all in that case. The proposed types would be a feature > of the static module. It wouldn’t be useful in single-huge-site > deployments, only for sites running on a single server (Nginx+PHP). or massive sites that use nginx+php/php-fpm on the same node. it’s a nice (and common) practice. also throw on a memcached instance to add any extra memory to the cluster 😉 ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 12:17pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/33 "2010-08-05T12:17:04Z")
On Thu, Aug 05, 2010 at 01:58:04PM +0400, Igor S. wrote: > Then it can be easy fixed by > > location ^~ /uploads/ { > or > location ~ ^/uploads/ { Sure. However this requires cooperation between the application user and the server admin, which isn’t always possible (e.g. in a shared hosting setup it’s infeasible to configure every application according to its needs; everything must be set up well enough to work with automated configuration). > I never liked this Apache idea of internal MIME-types such as > application/x-httpd-php, text/x-server-parsed-html, etc. > I believe it confuses and complicates things. The Apache approach to e.g. FastCGI is positively insane, but (for me at least) the major problem is tying everything to filesystem paths, not assigning everything a MIME type. Thankfully, those days are gone by, but I remember setting up a fake path to some nonexistent ScriptAlias’ed directory(?) just to run a FastCGI server. I sincerely hope Nginx never goes that way 😉 but if a URL has been resolved to a real file on disk, we do have a proper MIME type we could use. Apart from the internal types like you (and I) mentioned, Mike proposed a less controversial (IMHO) use case: type text/css { expires max; } I think it’s quite clean and conveys the idea better than: location ~ .css$ { expires max; } Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 11:58am UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/34 "2010-08-05T11:58:55Z")
On Thu, Aug 05, 2010 at 10:49:52AM +0200, Grzegorz N. wrote: > /index.php > traversal bugs…) but can upload /uploads/anythingyoulike.gif > Then it can be easy fixed by location ^~ /uploads/ { or location ~ ^/uploads/ { > > the image file as “/dir/1.gif/2.php” making exploit. I do not see > > how using types will help in a case when nginx ahs not access to remote > > filesystem. > > It won’t help at all in that case. The proposed types would be a feature > of the static module. It wouldn’t be useful in single-huge-site > deployments, only for sites running on a single server (Nginx+PHP). I never liked this Apache idea of internal MIME-types such as application/x-httpd-php, text/x-server-parsed-html, etc. I believe it confuses and complicates things. – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 12:22pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/35 "2010-08-05T12:22:56Z")
On Thu, Aug 5, 2010 at 3:16 AM, Grzegorz N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > type text/css { > Â expires max; > } > > I think it’s quite clean and conveys the idea better than: > > location ~ .css$ { > Â expires max; > } I won’t say that I am absolutely in support of this, just wanted to add in my few cents on what the syntax should be, if it was to be something. My biggest pet peeve is the conflicting location blocks. I’ve often mentioned a “super location” idea, something that gets executed at the very end of all the other rules, so that something like adding expires headers can be done at the very end. The idea of using this “type” methodology is nice though, as nginx could in theory factor it in at the very end before it spits out the content, examining the content-type header to determine “hey, this is text/css! I should apply these rules on it” and not having to setup regexp’ed locations that could conflict with other location blocks. However, the biggest thing here is to see if there is a magic way to stop “any url ending in .php to be parsed as PHP” using existing nginx configuration or a small patch. That would make anyone who says there is any sort of security hazard go back into their caves (as nginx rarely has anything to be concerned about!) ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 12:40pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/36 "2010-08-05T12:40:29Z")
On czw, sie 05, 2010 at 03:22:19 -0700, Michael S. wrote: > My biggest pet peeve is the conflicting location blocks. I’ve often > mentioned a “super location” idea, something that gets executed at the > very end of all the other rules, so that something like adding expires > headers can be done at the very end. I’d settle for a clean way to cover all of /foo (spanning several locations, some of them being regex ones) with authentication or other access controls. I’m currently using an ugly hack in Nginx code for that. So I guess we’re aiming for roughly the same thing. > The idea of using this “type” methodology is nice though, as nginx > could in theory factor it in at the very end before it spits out the > content, examining the content-type header to determine “hey, this is > text/css! I should apply these rules on it” and not having to setup > regexp’ed locations that could conflict with other location blocks. Would you expect it to be processed after static requests only or also after \*\_pass? > However, the biggest thing here is to see if there is a magic way to > stop “any url ending in .php to be parsed as PHP” using existing nginx > configuration or a small patch. That would make anyone who says there > is any sort of security hazard go back into their caves (as nginx > rarely has anything to be concerned about!) It’s effectively impossible if Nginx doesn’t run on the same node as the backend as it requires matching …/foo.php the URL with …/foo.php the file and acting upon the results. That’s why I think it belongs as an extension in the static module. Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 12:45pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/37 "2010-08-05T12:45:10Z")
On Thu, Aug 05, 2010 at 12:16:32PM +0200, Grzegorz N. wrote: > needs; everything must be set up well enough to work with automated > Thankfully, those days are gone by, but I remember setting up a fake > I think it’s quite clean and conveys the idea better than: > > location ~ .css$ { > expires max; > } Well, how can you express this ``` location ~ ^/dev/.*\.css$ { root /path/to/dev; expires off; } location ~ \.css$ { root /path/to/production; expires max; } ``` using mime-types ? – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 12:45pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/38 "2010-08-05T12:45:45Z")
On Thu, Aug 5, 2010 at 3:40 AM, Grzegorz N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Would you expect it to be processed after static requests only or also > after \*\_pass? I don’t know 🙂 All I know is I want to apply rules like expires headers and such at the very end - those could be CSS/JS files being generated on the fly by PHP for instance (which is horrible, but oh well) and I’d like those to be treated just like static .css or .js files. A “type” fixes that, a filename regexp does not. It’s just an example. That example -may- have just unraveled my whole point of the discussion, too. It’s late 🙂 > It’s effectively impossible if Nginx doesn’t run on the same node as the > backend as it requires matching …/foo.php the URL with …/foo.php the > file and acting upon the results. That’s why I think it belongs as an > extension in the static module. understood. I’d say most of us are using things like try\_files and if (-e $request\_filename) type checks already, so nginx is aware of the files themselves, hence that interesting idea of a try\_files $uri inside of the location for .php files… unless I’m missing something which is blatantly obvious in the internals of course 🙂 ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 12:50pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/39 "2010-08-05T12:50:26Z")
On czw, sie 05, 2010 at 02:44:19 +0400, Igor S. wrote: > ``` > } > > ``` > > using mime-types ? Dunno, how about: location /dev { root /path/to/dev; # … type text/css { expires off; } } location / { root /path/to/production; # … type text/css { expires max; } } 1. Yes, this requires nesting type{} in location{} 2. I don’t expect everybody to drop regex locations in favour of type{}, I just expect it’ll make some types of configuration easier, just like try\_files did. Best regards, Grzegorz N. ---
**Author:** ![Raina\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/b487fb/32.png) [@Raina\_G](https://www.ruby-forum.com/u/Raina_G)\ **Post date:** [August 5, 2010, 1:09pm UTC](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407/40 "2010-08-05T13:09:45Z")
On Thu, Aug 05, 2010 at 12:53:26PM +0200, Grzegorz N. wrote: > Yes, Nginx is aware of files, of course 🙂 but unlike Apache, where > everything must be a file, it prefers operating on URLs and uses files > as late as possible. That’s my understanding of its philosophy, at > least. I believe NSCA/Apache was being developed primarily as static web server. So all these , , .htaccess, etc exist. Then mod\_proxy module has been added. In nginx static files processing is just a part of functionality, so it uses "location"s only (analog of Apache’s ) to concentrate processing in a single place. – Igor S. > **[Igor Sysoev](http://sysoev.ru/en/)** [Previous page](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407.md?page=1) [Next page](https://www.ruby-forum.com/t/equivalent-of-apaches-setenv-variable/192407.md?page=3)