Forum: NGINX .htaccess style support in existing nginx

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: 
http://forum.nginx.org/read.php?2,232176,232176#msg-232176

2012/10/25 rahul286 <nginx-forum@nginx.us>:
> 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 ;-)

Regards, Andre

[1] http://www.php.net/manual/en/function.htmlspecialchars.php

Thanks for warning. :-)

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: 
http://forum.nginx.org/read.php?2,232176,232197#msg-232197

On 25 October 2012 07:08, rahul286 <nginx-forum@nginx.us> 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 Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

Thanks for a really scary example! :D

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

In fact for a wordpress blog-network which use our plugin
http://wordpress.org/extend/plugins/nginx-helper/

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. :D

Posted at Nginx Forum: 
http://forum.nginx.org/read.php?2,232176,232203#msg-232203

By the way more details about problem we are trying to solve are here -
https://github.com/rtCamp/nginx-helper/issues/9

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: 
http://forum.nginx.org/read.php?2,232176,232204#msg-232204

2012/10/25 rahul286 <nginx-forum@nginx.us>:
> 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 Matthews be careful of harmful code.

Regards, André

Thanks for suggestion André. :-)

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: 
http://forum.nginx.org/read.php?2,232176,232247#msg-232247

On 26 October 2012 09:38, rahul286 <nginx-forum@nginx.us> 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 Matthews // Oxford, London, UK
http://www.jpluscplusm.com/contact.html

@Jonathan

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

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: 
http://forum.nginx.org/read.php?2,232176,232253#msg-232253