|
|
|
|
|
|
by anttiok
3867 days ago
|
|
|
Can you expand on that idea? For Rumprun, it's not very many minutes of work to set things up so that you have a lower readonly file system layer (immutable across restarts) and then a memory file system on top of that (for purposes of applications insisting to modify "readonly" files). But, of course, it's not very many minutes only if you know the ins and outs of the backend system, and that's not the level of usability what we're aiming for. So, if writing "readonly" files is a widely desired feature, we should probably somehow support it as part of the general infrastructure in Rumprun so that it just works even if you don't know the ins and out of the underlying system. |
|
|
The core issue with PHP is that most applications think they can just drop files in all sorts of places depending on what page was requested and to what user is logged in and what the state of the database was... and it always depends on what the application is. Some of these files are user uploads, logs, or cache for performance sake (more conflicting here is that PHP will cache op codes into memory based on the filesystem structure).
It's also pretty common to see exploits where an attacker injects code into a PHP file, so making a subset of this immutable would be a big win IMO when talking to business and IT about the list of reasons I would use this in production.