6 ms·

They use php-fpm pools where each website gets it's own uid:gid and the php process runs as that user. Then standard linux file permissions so you can only acce

by enkrs 6y ago

They use php-fpm pools where each website gets it's own uid:gid and the php process runs as that user. Then standard linux file permissions so you can only access your own uid files. To access web assets from nginx/apache, they add file permissions wich standard Linux acls. Altough not fancy, the security model is actually quite mature. Security problems in these servers come from misconfigured permissions and scripts, not the security stack.

arp242 6y ago
Supporting shared hosting well is probably a large reason for PHP's success.
- nkozyra 6y ago
  Sure, but there's nothing inherent to the language that fueled that. They could have done that with Python, for example. Rather, it was popular software like bulletin boards and blogging platforms that built the demand. PHP used to have one of the lowest barriers to entry because you could get by with plain HTML and incrementally add business logic inline.
  - sneak 6y ago
    Python webserver support doesn't support SSI-style open and closing code tags in HTML files to be executed per-request, last I checked. Is there anything like php or bml (bradfitz's equivalent for perl) for python, so that you can put code right in your html to be replaced at serving time with the code's output?
    - shoeffner 6y ago
      https://docs.python.org/3/library/cgi.html https://docs.python.org/3/library/cgi.html All your prints are essentially sent as response with CGI, but I think for Python WSGI is the standard you should use, and you can e.g. use jinja to render HTML with templates where you can use variables, certain functions, etc. Is that what you are looking for?
    - tyingq 6y ago
      PSP (python server pages) is pretty close to that. I don't think it is terribly popular. There's also Spyce.
  - 40four 6y ago
    I’ve always found that very interesting about PHP. It can do both, be a standalone scripting language, and a templating engine. Not that I would ever recommend using as a templating language in 2021 :) but it’s cool that it can do that without any external library.
    - ljm 6y ago
      It's so cool that even though it's already a templating language, it's a templating language that hosts other templating languages too (Smarty, Twig).
  - rob74 6y ago
    Sure, you could even argue that PHP was a success despite the PHP language (which was, in the beginning, only a cobbled-together templating language, and then, to Rasmus Lerdorf's dismay, people started to implement their backend logic in the templating language), and Python could have done it, but, well, they didn't...
    - withinboredom 6y ago
      now, you can even write actors in PHP: https://github.com/dapr/php-sdk#actors https://github.com/dapr/php-sdk#actors
  - giantrobot 6y ago
    > Sure, but there's nothing inherent to the language that fueled that. They could have done that with Python, for example. Not quite true. With shared hosting it was (is?) uncommon for a user directory to have ExecCGI enabled. If you wanted scripts to run they had to live in the cgi-bin directory. Additionally mod_rewrite could be expensive on low powered servers. This all meant doing anything dynamic meant "ugly" URLs and meta tag forwards if you were on such a shared host. It was also non-trivial amounts of effort to get some random CGI script working since you needed to know enough to get the shebang path correct for the server and set the right permissions. Contrast this to PHP where you dropped a .php file into your user directory and you've got some dynamic content. Platforms built on PHP became popular because you could upload them to your user folder and they just sort of worked. There were no special executable paths, no shebangs, and no execute permissions to set. Perl was huge in the CGI space for a long time but the (consumer) content platforms built on it weren't nearly as successful because of the difficulty of mere mortals getting them running on their shared hosting plans.
  - arp242 6y ago
    Not really; PHP had many features to make this easier; for example "safe_mode" and "open_basedir". These are not easily replicated in a stock Python by just "flicking a switch", even today (although the need for that today is a lot less than it was in 2000, and PHP even removed safe_mode). Not that these measures were perfect, but they were mostly "good enough". There was a reason that in ~2000-2005 you could find PHP shared hosts for $1/$2 month, and that Python/Perl/etc. shared hosts were much harder to find and more expensive. People started using PHP bulletin boards and blogging platforms because at the time it was easier and cheaper to run, but that's an effect and not a cause.
    - tekknik 6y ago
      > These are not easily replicated in a stock Python by just "flicking a switch", even today. Chroot, containers/jails, SElinux, these are all OSwide and would protect PHP just as much a Python or nodejs. There’s a reason PHP is dying off.
      - arp242 6y ago
        These either weren't available at all in 2000 or very new and much harder to set up. You need to consider the state of things 20 years ago, not how they are today.
        tekknik 6y ago
        chroot and jails have been around for a while, i don’t know the date but since ive used bsd and linux they’ve been there. definitely during this era. selinux was launched in 2000.
  - icedchai 6y ago
    Deployment? PHP made "deployment" very simple. On the other hand, Python is complicated to deploy even today.
  - asiachick 6y ago
    PHP succeed precisely because of how it executes .php files directly as scripts from a single running instance. This allowed it to be the shared hosting solution because it uses far far less resources than a similar python solution. Python is great if you want to run your own server or VM per site. It's not so great if you want to run a shared server and it's shared servers (not VMs) that brought the price down and therefore opened the floodgates of allowing people to run their own sites cheaply and easily.
archi42 6y ago
With the recent problem in sudo, I suspect this to be a likely cause. The typical shared hosting stack uses that somewhere, so servers will have it installed. A fast, malicious user (and a slow update process) is enough to get root on one machine and penetrate the rest of the net from there (can still be avoided, but requires some effort). Just a guess, of course.

by enkrs 6y ago

arp242 6y ago

Supporting shared hosting well is probably a large reason for PHP's success.

nkozyra 6y ago
Sure, but there's nothing inherent to the language that fueled that. They could have done that with Python, for example. Rather, it was popular software like bulletin boards and blogging platforms that built the demand. PHP used to have one of the lowest barriers to entry because you could get by with plain HTML and incrementally add business logic inline.
- sneak 6y ago
  Python webserver support doesn't support SSI-style open and closing code tags in HTML files to be executed per-request, last I checked. Is there anything like php or bml (bradfitz's equivalent for perl) for python, so that you can put code right in your html to be replaced at serving time with the code's output?
  - shoeffner 6y ago
    https://docs.python.org/3/library/cgi.html https://docs.python.org/3/library/cgi.html All your prints are essentially sent as response with CGI, but I think for Python WSGI is the standard you should use, and you can e.g. use jinja to render HTML with templates where you can use variables, certain functions, etc. Is that what you are looking for?
  - tyingq 6y ago
    PSP (python server pages) is pretty close to that. I don't think it is terribly popular. There's also Spyce.
- 40four 6y ago
  I’ve always found that very interesting about PHP. It can do both, be a standalone scripting language, and a templating engine. Not that I would ever recommend using as a templating language in 2021 :) but it’s cool that it can do that without any external library.
  - ljm 6y ago
    It's so cool that even though it's already a templating language, it's a templating language that hosts other templating languages too (Smarty, Twig).
- rob74 6y ago
  Sure, you could even argue that PHP was a success despite the PHP language (which was, in the beginning, only a cobbled-together templating language, and then, to Rasmus Lerdorf's dismay, people started to implement their backend logic in the templating language), and Python could have done it, but, well, they didn't...
  - withinboredom 6y ago
    now, you can even write actors in PHP: https://github.com/dapr/php-sdk#actors https://github.com/dapr/php-sdk#actors
- giantrobot 6y ago
  > Sure, but there's nothing inherent to the language that fueled that. They could have done that with Python, for example. Not quite true. With shared hosting it was (is?) uncommon for a user directory to have ExecCGI enabled. If you wanted scripts to run they had to live in the cgi-bin directory. Additionally mod_rewrite could be expensive on low powered servers. This all meant doing anything dynamic meant "ugly" URLs and meta tag forwards if you were on such a shared host. It was also non-trivial amounts of effort to get some random CGI script working since you needed to know enough to get the shebang path correct for the server and set the right permissions. Contrast this to PHP where you dropped a .php file into your user directory and you've got some dynamic content. Platforms built on PHP became popular because you could upload them to your user folder and they just sort of worked. There were no special executable paths, no shebangs, and no execute permissions to set. Perl was huge in the CGI space for a long time but the (consumer) content platforms built on it weren't nearly as successful because of the difficulty of mere mortals getting them running on their shared hosting plans.
- arp242 6y ago
  Not really; PHP had many features to make this easier; for example "safe_mode" and "open_basedir". These are not easily replicated in a stock Python by just "flicking a switch", even today (although the need for that today is a lot less than it was in 2000, and PHP even removed safe_mode). Not that these measures were perfect, but they were mostly "good enough". There was a reason that in ~2000-2005 you could find PHP shared hosts for $1/$2 month, and that Python/Perl/etc. shared hosts were much harder to find and more expensive. People started using PHP bulletin boards and blogging platforms because at the time it was easier and cheaper to run, but that's an effect and not a cause.
  - tekknik 6y ago
    > These are not easily replicated in a stock Python by just "flicking a switch", even today. Chroot, containers/jails, SElinux, these are all OSwide and would protect PHP just as much a Python or nodejs. There’s a reason PHP is dying off.
    - arp242 6y ago
      These either weren't available at all in 2000 or very new and much harder to set up. You need to consider the state of things 20 years ago, not how they are today.
      - tekknik 6y ago
        chroot and jails have been around for a while, i don’t know the date but since ive used bsd and linux they’ve been there. definitely during this era. selinux was launched in 2000.
- icedchai 6y ago
  Deployment? PHP made "deployment" very simple. On the other hand, Python is complicated to deploy even today.
- asiachick 6y ago
  PHP succeed precisely because of how it executes .php files directly as scripts from a single running instance. This allowed it to be the shared hosting solution because it uses far far less resources than a similar python solution. Python is great if you want to run your own server or VM per site. It's not so great if you want to run a shared server and it's shared servers (not VMs) that brought the price down and therefore opened the floodgates of allowing people to run their own sites cheaply and easily.

archi42 6y ago

With the recent problem in sudo, I suspect this to be a likely cause. The typical shared hosting stack uses that somewhere, so servers will have it installed. A fast, malicious user (and a slow update process) is enough to get root on one machine and penetrate the rest of the net from there (can still be avoided, but requires some effort). Just a guess, of course.