Forum: NGINX .htaccess style support in existing nginx

2974d09ac2541e892966b762aad84943?d=identicon&s=25 rahul286 (Guest)
on 2012-10-25 08:09
(Received via mailing list)
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
B72bff74dc272c099eef49bae550fffb?d=identicon&s=25 Andre Jaenisch (Guest)
on 2012-10-25 11:50
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 rahul286 (Guest)
on 2012-10-25 12:03
(Received via mailing list)
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
34011bc56457235a2caa5ed1d4a29f3c?d=identicon&s=25 Jonathan Matthews (Guest)
on 2012-10-25 13:57
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 rahul286 (Guest)
on 2012-10-25 14:52
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 rahul286 (Guest)
on 2012-10-25 14:58
(Received via mailing list)
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
B72bff74dc272c099eef49bae550fffb?d=identicon&s=25 Andre Jaenisch (Guest)
on 2012-10-26 10:20
(Received via mailing list)
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é
2974d09ac2541e892966b762aad84943?d=identicon&s=25 rahul286 (Guest)
on 2012-10-26 10:39
(Received via mailing list)
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
34011bc56457235a2caa5ed1d4a29f3c?d=identicon&s=25 Jonathan Matthews (Guest)
on 2012-10-26 12:01
(Received via mailing list)
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
2974d09ac2541e892966b762aad84943?d=identicon&s=25 rahul286 (Guest)
on 2012-10-26 13:44
(Received via mailing list)
@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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.