3 ms·

Isn't the support for htaccess basically one of the only reasons one would use apache in favor of nginx? I.e. that you can provide users some configuration poss

by hannob 10y ago

Isn't the support for htaccess basically one of the only reasons one would use apache in favor of nginx? I.e. that you can provide users some configuration possibilities on a multiuser system? I run some servers with an apache/php/mysql configuration, we looked multiple times into nginx and that was always the problem: A user wouldn't be able to install any standard CMS without asking the admins for changes to the server config.

tuananh 10y ago
we have containers for that now right?
- the_duke 10y ago
  If you are hosting many small apache/php/mysql based sites, you most certainly do not want to run a seperate server instance for each...
  - marktangotango 10y ago
    Unfortunate the parent was downvoted, it's a valid conjecture, and a consequence of "containerize all the things" not a lot of people think through. Simply answer the question; how many containers can any particular machine host? Ten's or hundreds? Depends on the hardware obviously, but there is a limit. So if each container is a paying customer, and you're in the busines of hosting containers (ie hyper.sh), that dictates your hardware/profit ratio. Then consider a single multi-tenant server (ie apache hosting 10,000 low to medium use shared sites on the same hardware). Vastly more potential users (paying customers) on the same hardware. Obviously this story has already played out and shared hosting has been in decline for years due to problems with the model; resource starvation (more active sites hogging cpu etc) and flexibility (cpanel). With containers you get so many benefits; infinite customizable, easy provisioning and deployment, tool support, etc. But the value proposition remains. Multi tenant servers make so much sense (and potentially a lot more money per hardware unit), but resource limiting (cpu, heap, disk, io) at the application level has never been implemented to really make a a viable option. OS level limiting (ie cpulimit) is available, and that's what container hosts use for resource limiting. My conjecture is that a suitable multi tenant server that can limit heap, cpu, and io at the account level should lower hosting costs by at least an order of magnitude. WHy pay $5 a month for a small container when you can pay $5 a year?
PuffinBlue 10y ago
Did you look at the 'include' directive in Nginx? I'm not sure about the security implications as I use this just for servers I control, but you can use a (just example naming) nginx.conf file in the website root, and use the 'include' directive in the main config file to read from that. That's how I use Wordpress with Nginx to automatically write things like Yoast's Wordpress SEO or iThemes Security rules. Something like: include /var/www/domain/htdocs/nginx.conf; Seems like there would be similar security concerns to using a .htaccess file but I've not looked into that in any detail.
- andwur 10y ago
  If the included file is writable by the PHP user then I would say that poses a reasonably high security risk; potential privesc, information disclosure, RCE. Of course an attacker would need the ability to manipulate local files as the PHP user, but that isn't much of a stretch. Under a typical install, e.g. Debian, Ubuntu, etc, nginx parses the configuration files as root thus any exploit of the config parser gains full root access as the nginx master process doesn't drop caps. Depending on where the include line is placed it may be possible for an attacker to create server blocks allowing them to execute arbitrary PHP by permitting PHP execution from a directory with PHP write access, e.g. `wp-upload`. Assisting exfiltration of data by allowing easy remote access to the filesystem. Possibly proxy all traffic through an attacker controlled script or host. Exposing local services to the outside world. I'm sure there's plenty of other interesting little attacks possible if given enough time to play around with it. If at all possible I would avoid permitting unprivileged r|w access to nginx configuration files.
  - PuffinBlue 10y ago
    > If the included file is writable by the PHP user then I would say that poses a reasonably high security risk It wouldn't be, just writable by the ordinary user. That pretty much negates the rest of what you said except for... > Of course an attacker would need the ability to manipulate local files as the PHP user, but that isn't much of a stretch. If that's happening you've got far worse things going on than having a nginx.conf file around.
mfontani 10y ago
Not the only one; in my case the nginx "rewrite rules" aren't as powerful as Apache's, and it'd be a huge PITA to migrate them over… :|

by hannob 10y ago

tuananh 10y ago

we have containers for that now right?

the_duke 10y ago
If you are hosting many small apache/php/mysql based sites, you most certainly do not want to run a seperate server instance for each...
- marktangotango 10y ago
  Unfortunate the parent was downvoted, it's a valid conjecture, and a consequence of "containerize all the things" not a lot of people think through. Simply answer the question; how many containers can any particular machine host? Ten's or hundreds? Depends on the hardware obviously, but there is a limit. So if each container is a paying customer, and you're in the busines of hosting containers (ie hyper.sh), that dictates your hardware/profit ratio. Then consider a single multi-tenant server (ie apache hosting 10,000 low to medium use shared sites on the same hardware). Vastly more potential users (paying customers) on the same hardware. Obviously this story has already played out and shared hosting has been in decline for years due to problems with the model; resource starvation (more active sites hogging cpu etc) and flexibility (cpanel). With containers you get so many benefits; infinite customizable, easy provisioning and deployment, tool support, etc. But the value proposition remains. Multi tenant servers make so much sense (and potentially a lot more money per hardware unit), but resource limiting (cpu, heap, disk, io) at the application level has never been implemented to really make a a viable option. OS level limiting (ie cpulimit) is available, and that's what container hosts use for resource limiting. My conjecture is that a suitable multi tenant server that can limit heap, cpu, and io at the account level should lower hosting costs by at least an order of magnitude. WHy pay $5 a month for a small container when you can pay $5 a year?

PuffinBlue 10y ago

Did you look at the 'include' directive in Nginx? I'm not sure about the security implications as I use this just for servers I control, but you can use a (just example naming) nginx.conf file in the website root, and use the 'include' directive in the main config file to read from that. That's how I use Wordpress with Nginx to automatically write things like Yoast's Wordpress SEO or iThemes Security rules. Something like: include /var/www/domain/htdocs/nginx.conf; Seems like there would be similar security concerns to using a .htaccess file but I've not looked into that in any detail.

andwur 10y ago
If the included file is writable by the PHP user then I would say that poses a reasonably high security risk; potential privesc, information disclosure, RCE. Of course an attacker would need the ability to manipulate local files as the PHP user, but that isn't much of a stretch. Under a typical install, e.g. Debian, Ubuntu, etc, nginx parses the configuration files as root thus any exploit of the config parser gains full root access as the nginx master process doesn't drop caps. Depending on where the include line is placed it may be possible for an attacker to create server blocks allowing them to execute arbitrary PHP by permitting PHP execution from a directory with PHP write access, e.g. `wp-upload`. Assisting exfiltration of data by allowing easy remote access to the filesystem. Possibly proxy all traffic through an attacker controlled script or host. Exposing local services to the outside world. I'm sure there's plenty of other interesting little attacks possible if given enough time to play around with it. If at all possible I would avoid permitting unprivileged r|w access to nginx configuration files.
- PuffinBlue 10y ago
  > If the included file is writable by the PHP user then I would say that poses a reasonably high security risk It wouldn't be, just writable by the ordinary user. That pretty much negates the rest of what you said except for... > Of course an attacker would need the ability to manipulate local files as the PHP user, but that isn't much of a stretch. If that's happening you've got far worse things going on than having a nginx.conf file around.

mfontani 10y ago

Not the only one; in my case the nginx "rewrite rules" aren't as powerful as Apache's, and it'd be a huge PITA to migrate them over… :|