11–20 of 22 posts
Earlier quoted context omitted.
In theory, to make the temp/cache directories more secure I imagine
This would make sense if it created those directories, but IMHO it should fail to start if the path exists and isn't owned by www process. The function that does chown() is even called ngx_create_paths().
Seems like NGINX logic should be, if the path exists, it must have correct permissions already. If not, just fail to start.
What other NGINX directive paths besides "client_body_temp_path" actually change the owner on-startup? Seems like NGINX logic should be, if the path exists, it must have correct permissions already. If not, just fail to start.
I am sure there are other ones but I have not had a chance to investigate further. Another commented mentioned this particular problem is in ngx_create_paths so that would be a good place to start looking.
The key is to find paths that happen in the master process, not the workers.
Earlier quoted context omitted.
This would make sense if it created those directories, but IMHO it should fail to start if the path exists and isn't owned by www process. The function that does chown() is even called ngx_create_paths().
I agreed, would at least consider it a bug if not a security issue.
Why would you ever include user owned configs in nginx?
Earlier quoted context omitted.
Because nginx AFAIK does not have something like Apache's .htaccess. Yes, htaccess is ugly but at least a server operator can restrict the users from pwning the machine and only allow rewrite-configs.
That is exactly the reason. and is the main difference between Apache mode and Nginx mode in W3TC. The plugin needs to be able to create URL rewriting rules on the fly, and nginx gives them no sane way to do it. Htaccess sucks for various reasons, but most of the suck can be worked around.
Also, there is no reason to start nginx under root on linux, just give the binary required net bind capability and start under normal user.
This is a very interesting attack vector. There are many situations where less privileged users can inject stuff into an nginx config.
Earlier quoted context omitted.
Because nginx AFAIK does not have something like Apache's .htaccess. Yes, htaccess is ugly but at least a server operator can restrict the users from pwning the machine and only allow rewrite-configs.
That is exactly the reason. and is the main difference between Apache mode and Nginx mode in W3TC. The plugin needs to be able to create URL rewriting rules on the fly, and nginx gives them no sane way to do it. Htaccess sucks for various reasons, but most of the suck can be worked around.
http://serverfault.com/questions/441235/maintaining-redirect...
Earlier quoted context omitted.
That is exactly the reason. and is the main difference between Apache mode and Nginx mode in W3TC. The plugin needs to be able to create URL rewriting rules on the fly, and nginx gives them no sane way to do it. Htaccess sucks for various reasons, but most of the suck can be worked around.
What exactly does it do on the fly? Unless the plugin is running under the same user as nginx's master process, which is usually root, it won't be able to send SIGHUP to the master process and reload nginx.conf. So, nothing can be on the fly here, it's probably just one of those fancy ways to make plugin installation "easier" and create configs on behalf of the user. Also, there is no reason to start nginx under root…
Other plugins like iThemes Security will populate the nginx.conf with banned IP and the such, so it can update on a fairly regular basis.