4 ms·

He mentions how mod_php allowed web hosts to support thousands of users on a single server, but doesn't that run all the different users' scripts under the same

by ptx 7y ago

He mentions how mod_php allowed web hosts to support thousands of users on a single server, but doesn't that run all the different users' scripts under the same Unix user account, letting everyone mess with each other's stuff?

deleted 7y ago
[deleted]
deleted 7y ago
[deleted]
nkozyra 7y ago
Mess with each other's stuff in what regard? Sites could be sandboxed but yes everything was running under some web server user account, and it was a single machine so you could ddos anyone.
gbrunacci 7y ago
Not really, you were able to run everything inside a virtual host under a specific user+group. That was key for cPanel which is what you would usually get when purchasing a shared hosting account in the 2000s until "the cloud" became a thing. https://cpanel.net https://cpanel.net
chubot 7y ago
A single server has many Unix accounts! That’s how all servers worked before the cloud and VMs and containers. The isolation isn’t perfect, but it’s good enough for good sys admins to manage. File system permissions work, etc. It's much simpler than the cloud. For a historical perspective, MS-DOS was a single user OS, while Unix was always multi-user. Windows NT / 2000 / XP was more like Unix since networking (LAN and Internet) became more important. I still run my blog on shared hosting [1] and it works great. (Several of my posts have been on the HN front page and it always handles the load fine. Including one at the #1 or #2 spot.) https://en.wikipedia.org/wiki/Shared_web_hosting_service https://en.wikipedia.org/wiki/Shared_web_hosting_service The Twitter pic here is a good analogy for blogs in the cloud: https://christine.website/blog/the-cult-of-kubernetes-2019-09-07 https://christine.website/blog/the-cult-of-kubernetes-2019-0...
- ptx 7y ago
  I'm aware, but maybe I didn't phrase my question well. CGI scripts, including PHP when run in that mode, fork a new process as the appropriate user - as you say. But mod_php runs in the Apache process instead, for better performance. What I'm not sure about is whether it changes the user somehow when handling the request or just runs everything as the Apache user. I believe it's the latter since I've seen various modules that claim to address the problem.
  - tpetry 7y ago
    Everything was/is run as the apache user. PHP tried to make it secure by restricting the folders a script was allowed to access but over the years so many ways to break had been found that a fastcgi process per user showed its the best solution. I think the system was called basedir restriction.
  - chubot 7y ago
    Yeah that's true, I misunderstood. He did mention in the talk that mod_perl was infeasible for this use case because it gave the user too much control. One user could override the Apache base_dir and redirect another user's traffic to his pages!!! He said that as a result, hosting providers in the 90's would charge 100x the price for mod_perl hosting on a dedicated bare metal box, vs mod_php which could be shared. Didn't know that. So I guess the answer is that mod_php has to be careful and not expose too many Apache hooks to the user. The PHP interpreter does seem to have some unique qualities that make it good for embedding, compared with Perl, Python, Ruby.
antod 7y ago
From hazy memory there were two ways of configuring apache/mod_php. 1) The web server ran with a common account (eg www-data), and only had read access to users files. 2) The web server could be configured to run each site in the context of the file owners. The advantages of 1) were that your website didn't have write access to your files. The advantages of 2) were that other peoples websites didn't have read access to your files, but your own site could overwrite them. I only felt "safe"(ish) on a dedicated server, using option 1).
- ptx 7y ago
  This means that everyone can read each other's configuration files, though, and thus connect to each other's databases, doesn't it? (Edit: Ah, that's why you had a dedicated server.)
rob-olmos 7y ago
For mod_php, they'd run as the same httpd user account and could mess with other user's stuff if they were set to be httpd writeable. Other isolation levels were needed, like an MPM that would run vhosts as their own user, or a vhost level chroot. Alternatively, there was php-cgi via suexec, but it didn't have the persistent qualities of mod_php.
kalleboo 7y ago
PHP had safe_mode which tried to solve the problem https://www.php.net/manual/en/features.safe-mode.php https://www.php.net/manual/en/features.safe-mode.php also open_basedir https://www.php.net/manual/en/ini.core.php#ini.open-basedir https://www.php.net/manual/en/ini.core.php#ini.open-basedir

by ptx 7y ago

deleted 7y ago

[deleted]

deleted 7y ago

[deleted]

nkozyra 7y ago

Mess with each other's stuff in what regard? Sites could be sandboxed but yes everything was running under some web server user account, and it was a single machine so you could ddos anyone.

gbrunacci 7y ago

Not really, you were able to run everything inside a virtual host under a specific user+group. That was key for cPanel which is what you would usually get when purchasing a shared hosting account in the 2000s until "the cloud" became a thing. https://cpanel.net https://cpanel.net

chubot 7y ago

A single server has many Unix accounts! That’s how all servers worked before the cloud and VMs and containers. The isolation isn’t perfect, but it’s good enough for good sys admins to manage. File system permissions work, etc. It's much simpler than the cloud. For a historical perspective, MS-DOS was a single user OS, while Unix was always multi-user. Windows NT / 2000 / XP was more like Unix since networking (LAN and Internet) became more important. I still run my blog on shared hosting [1] and it works great. (Several of my posts have been on the HN front page and it always handles the load fine. Including one at the #1 or #2 spot.) https://en.wikipedia.org/wiki/Shared_web_hosting_service https://en.wikipedia.org/wiki/Shared_web_hosting_service The Twitter pic here is a good analogy for blogs in the cloud: https://christine.website/blog/the-cult-of-kubernetes-2019-09-07 https://christine.website/blog/the-cult-of-kubernetes-2019-0...

ptx 7y ago
I'm aware, but maybe I didn't phrase my question well. CGI scripts, including PHP when run in that mode, fork a new process as the appropriate user - as you say. But mod_php runs in the Apache process instead, for better performance. What I'm not sure about is whether it changes the user somehow when handling the request or just runs everything as the Apache user. I believe it's the latter since I've seen various modules that claim to address the problem.
- tpetry 7y ago
  Everything was/is run as the apache user. PHP tried to make it secure by restricting the folders a script was allowed to access but over the years so many ways to break had been found that a fastcgi process per user showed its the best solution. I think the system was called basedir restriction.
- chubot 7y ago
  Yeah that's true, I misunderstood. He did mention in the talk that mod_perl was infeasible for this use case because it gave the user too much control. One user could override the Apache base_dir and redirect another user's traffic to his pages!!! He said that as a result, hosting providers in the 90's would charge 100x the price for mod_perl hosting on a dedicated bare metal box, vs mod_php which could be shared. Didn't know that. So I guess the answer is that mod_php has to be careful and not expose too many Apache hooks to the user. The PHP interpreter does seem to have some unique qualities that make it good for embedding, compared with Perl, Python, Ruby.

antod 7y ago

From hazy memory there were two ways of configuring apache/mod_php. 1) The web server ran with a common account (eg www-data), and only had read access to users files. 2) The web server could be configured to run each site in the context of the file owners. The advantages of 1) were that your website didn't have write access to your files. The advantages of 2) were that other peoples websites didn't have read access to your files, but your own site could overwrite them. I only felt "safe"(ish) on a dedicated server, using option 1).

ptx 7y ago
This means that everyone can read each other's configuration files, though, and thus connect to each other's databases, doesn't it? (Edit: Ah, that's why you had a dedicated server.)

rob-olmos 7y ago

For mod_php, they'd run as the same httpd user account and could mess with other user's stuff if they were set to be httpd writeable. Other isolation levels were needed, like an MPM that would run vhosts as their own user, or a vhost level chroot. Alternatively, there was php-cgi via suexec, but it didn't have the persistent qualities of mod_php.

kalleboo 7y ago

PHP had safe_mode which tried to solve the problem https://www.php.net/manual/en/features.safe-mode.php https://www.php.net/manual/en/features.safe-mode.php also open_basedir https://www.php.net/manual/en/ini.core.php#ini.open-basedir https://www.php.net/manual/en/ini.core.php#ini.open-basedir