4 ms·

Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't?

codetrotter 4y ago
> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? In theory yes. In practice no. I think a big reason that PHP grew popular years ago was that basically all you needed in order to set up a PHP site on a host was FTP access, and in certain cases DB credentials. For example, case in point, for WordPress you only need FTP and DB access. Certainly it was the case for me back in the day, when I started learning to program with PHP. I was still using Windows back then and I knew nothing about Linux or any of the other Unix-likes at the time. All I had was my Windows XP computers with XAMPP, and free hosting which provided me with FTP access. Many free hosts would give you MySQL DB credentials also I think. Cron and things like that would have been beyond my abilities at the time, and beyond what I was given access to by the free hosting companies.
- sgbeal 4y ago
  >> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? > In theory yes. In practice no. FWIW, after my one and only Wordpress installation was cracked via a vulnerability identical to the one reported in this thread (back in 2010-ish), i did exactly that: made all of the files and dirs read-only to the web user, and made the read/write only during upgrades. Since ditching that site, though, a couple of years later, WP has remained on my blacklist and i've neither touched it nor recommended its use (and actively recommend against it for anyone who asks because of its long, glorious history of being cracked). To this day, WP is still the only server-side software i've ever run which was cracked from the outside.
snowwrestler 4y ago
When I ran self-hosted Wordpress sites I wrote “lock” and “unlock” shell scripts that would alter file/directory permissions so Wordpress could install updates on a fixed schedule. We could also “unlock” and push updates by hand if a patch seemed critical. But, we were running our own Linux servers and had some idea of what we were doing. Many Wordpress site admins don’t. And Wordpress community has decided to err on the side of fast and easy patching over ideal server settings. And honestly it’s hard to fault that decision; the vast majority of attempts on WP sites target known and patched vulnerabilities. Even this article notes “sites running outdated or unpatched versions of these WordPress tools are at risk.” (emphasis mine) Anything that helps people patch faster is probably the right choice for the WP community.
- deafpolygon 4y ago
  This is what I did when I was admin of a multi-site WordPress install (over 6,000 individual blogs hosted via this one instance). Too many people wanted their own plugins and themes, so I had to come up with a secure method for updating and controlling what gets inside.

codetrotter 4y ago

> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? In theory yes. In practice no. I think a big reason that PHP grew popular years ago was that basically all you needed in order to set up a PHP site on a host was FTP access, and in certain cases DB credentials. For example, case in point, for WordPress you only need FTP and DB access. Certainly it was the case for me back in the day, when I started learning to program with PHP. I was still using Windows back then and I knew nothing about Linux or any of the other Unix-likes at the time. All I had was my Windows XP computers with XAMPP, and free hosting which provided me with FTP access. Many free hosts would give you MySQL DB credentials also I think. Cron and things like that would have been beyond my abilities at the time, and beyond what I was given access to by the free hosting companies.

sgbeal 4y ago
>> Could it have a cron that runs as a user with write access to perform upgrades, while publicly-accessible processes don't? > In theory yes. In practice no. FWIW, after my one and only Wordpress installation was cracked via a vulnerability identical to the one reported in this thread (back in 2010-ish), i did exactly that: made all of the files and dirs read-only to the web user, and made the read/write only during upgrades. Since ditching that site, though, a couple of years later, WP has remained on my blacklist and i've neither touched it nor recommended its use (and actively recommend against it for anyone who asks because of its long, glorious history of being cracked). To this day, WP is still the only server-side software i've ever run which was cracked from the outside.

snowwrestler 4y ago

When I ran self-hosted Wordpress sites I wrote “lock” and “unlock” shell scripts that would alter file/directory permissions so Wordpress could install updates on a fixed schedule. We could also “unlock” and push updates by hand if a patch seemed critical. But, we were running our own Linux servers and had some idea of what we were doing. Many Wordpress site admins don’t. And Wordpress community has decided to err on the side of fast and easy patching over ideal server settings. And honestly it’s hard to fault that decision; the vast majority of attempts on WP sites target known and patched vulnerabilities. Even this article notes “sites running outdated or unpatched versions of these WordPress tools are at risk.” (emphasis mine) Anything that helps people patch faster is probably the right choice for the WP community.

deafpolygon 4y ago
This is what I did when I was admin of a multi-site WordPress install (over 6,000 individual blogs hosted via this one instance). Too many people wanted their own plugins and themes, so I had to come up with a secure method for updating and controlling what gets inside.