.htaccess style support in existing nginx

Server NGINX
1

First, we can use “watch/monitor” files in linux for changes and execute
some command based on it.

Now, for a site lets put a “.nginxaccess” file to hold site specific
configuration (file will be writable by PHp, etc so web-site can update
it)

Then we can put in main site config “include $documentroot/.nginxaccess”

And also start a daemon to watch “/var/www/path/to/site/.nginxaccess”.
Whenever any changes are detected in
“/var/www/path/to/site/.nginxaccess” we
can test nginx config and reload it.

I will be giving this a try to see what issues I may face…

Please give your suggestions/opinion/alternative approach…

Goal is to allow wordpress like web-apps to update a site-specific nginx
config file AND have nginx auto-reloaded new config.

Posted at Nginx Forum:

2

2012/10/25 rahul286 [email protected]:

Now, for a site lets put a “.nginxaccess” file to hold site specific
configuration (file will be writable by PHp, etc so web-site can update it)
[…]
Whenever any changes are detected in “/var/www/path/to/site/.nginxaccess” we can
test nginx config and reload it.

Be careful concerning safety.
I’m afraid about maleficient code entered this way.
PHP provides functions like htmlspecialchars [1] to avoid this. Just a
word of warning :wink:

Regards, Andre

[1] PHP: htmlspecialchars - Manual

3

Thanks for warning. :slight_smile:

I guess a serious threat will be present when a malicious code injects
perl
scripts via nginx config…
Then request to some path will trigger perl script (which can be a
backdoor,
destruction program)

Posted at Nginx Forum:

4

On 25 October 2012 07:08, rahul286 [email protected] wrote:

Please give your suggestions/opinion/alternative approach…

Goal is to allow wordpress like web-apps to update a site-specific nginx
config file AND have nginx auto-reloaded new config.

In a multi-tenant system, which is what you appear to be aiming for,
this is a bad idea. A very bad idea.

Here are a few ways, as a customer, I could fuck you up:

In my /var/www/path/to/site/.nginxaccess:

START

} # close the “location /{” we assume we’re included from within
} # close the “server{” we must be included from within

server { # get access to some files we shouldn’t be allowed to see
listen 80;
server_name invalid.name1;
root /etc/;
}

server { # destroy someone else’s site
listen 80;
server_name invalid.name2;
root /var/www/path/to/someone/elses/site;

location / {
dav_methods PUT DELETE MKCOL COPY MOVE;
client_body_temp_path /var/www/path/to/someone/elses/site;
create_full_put_path on;
dav_access group:rwx all:rwx;
}
}

server { # DoS someone else’s site
listen 80;
server_name another.customer.on.this.server;
rewrite ^ http://google.com;
}

server { # re-enter our normal “server{” block, so nginx reloads OK
listen 80;
server_name invalid.name3;
location {

END

Don’t do this. It’s a bad idea.
The quality of badly-written nginx howtos, blogs, etc out there on the
web is poor enough without this flawed pattern gaining any traction or
exposure.

Cheers,
Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

5

Thanks for a really scary example! :smiley:

By the way, I was NOT planning this for shared environment.

In fact for a wordpress blog-network which use our plugin

Whenever users create new sites, the plugin add new sites id in map.conf
file (simple key value pair table of domain-name and numeric-ids for
efficient file-handling)

I was thinking to run a linux inotify based script to auto-reload nginx
whenever changes are detected in map.conf file.

After your example, I can add some sed commands to my script so any
chars
like "{’ and “}” will be stripped down!

At the end, you cannot guarantee security for anyone, no matter how safe
codes you develop. :smiley:

Posted at Nginx Forum:

6

By the way more details about problem we are trying to solve are here -

Another approach is to add PHP user to sudoers list and allow them to
execute only one command “www-data ALL=NOPASSWD: nginx -t && service
nginx
reload”

Again, other PHP script adding unwanted code can not be rules out!

Posted at Nginx Forum:

7

2012/10/25 rahul286 [email protected]:

Another approach is to add PHP user to sudoers list and allow them to execute
only one command “www-data ALL=NOPASSWD: nginx -t && service nginx reload”

Another suggesting to save your idea:
Fetch pen & paper and list commands users would need to change the
things you had in mind.
Then think of (or ask someone) wether it would be possible to do
anything harmful with just using these code.
If no → Allow users to execute those command.
If yes → Is your idea realisable in another way?

However, whitelisting (allow just certain commands) is always better
than blacklisting (forbid certain commands).
Maybe you could just save some settings using JSON or so.
But as shown above by Jonathan M. be careful of harmful code.

Regards, André

8

Thanks for suggestion André. :slight_smile:

Yes, we will take whitelisting approach only.

Rather than giving direct command like “nginx -t && service nginx
reload”
in sudoers list, we will create a small shell script, put it outside
web-writable path (so php/web-scripts cannot alter it)

www-data user will have sudo privilege on our script only

Posted at Nginx Forum:

9

@Jonathan

Thanks again for your inputs. This thread helped me learn few more
things.
:slight_smile:

Apart from that, I think, an application like web-based control-panel -
built for Nginx specially, will anyway need take care of all this.
Technically, if a script can write to a file and have new config updated
automatically, it will have to handle security issue as well.

Posted at Nginx Forum:

10

On 26 October 2012 09:38, rahul286 [email protected] wrote:

Yes, we will take whitelisting approach only.

Rather than giving direct command like “nginx -t && service nginx reload”
in sudoers list, we will create a small shell script, put it outside
web-writable path (so php/web-scripts cannot alter it)

www-data user will have sudo privilege on our script only

Don’t forget the simplest DoS of all - just create a config file
snippet that causes “nginx -t” to fail.
Then no-one can reload.

(It’s still a bad idea, sorry!)

Jonathan

Jonathan M. // Oxford, London, UK
http://www.jpluscplusm.com/contact.html