Unable to write in the "/code/themes" directory

[dirtsimple]

Unable to write in the "/code/themes" directory

[pjeby]

Hm. Well, you certainly do have a point there, in that an attacker could potentially leverage the writability of local.php to get an RCE. That can be addressed by changing the permissions once an instance is configured.

Unfortunately, local.php has to be writable because it's how all Mautic's configuration settings are saved, including the ones not set via the environment. The image's parameters_local.php loads local.php and then overrides it with the stuff from the environment. There really isn't a way around that at the moment, short of rewriting how Mautic saves its config files, to e.g. use a JSON file instead. (Which would be loads better, honestly, but I haven't had time to dig into that.)

At least it's a lot harder to wrangle an RCE out of the configuration screen's ability to write local.php, versus the RCE-waiting-to-happen that is theme/plugin uploading. To get an RCE out of that, you just have to compromise an admin account, and you're good to go.

That being said, I'm pretty sure the reason local.php isn't already local.json is performance: a PHP file can be cached as bytecode by php-fpm, while a JSON file can't. Which means that every hit (including hits to mtc.js, IIUC) would pay a performance penalty. So... ugh. This is why PHP can't have nice things... or at least can't have nice things that are also secure. :-(

[pjeby]

I bind-mount them read-only. For upgrades, I have a development container that gets upgrades first.

Note that making any code directory writable is destroying the defense-in-depth security system of the container. Allowing the web server to write code means that any exploit that writes to an executable PHP file equal a remote code execution vulnerability. With the default security settings, an exploit that allows writing files doesn't open a RCE vulnerability, because the server can't write to directories where code can be executed.

The developer user can write files, and you should use that user to run command-line tools, e.g. docker-compose exec mycontainer as-developer app/console blah blah....

[karser]

Good point, thanks.
I noticed that file local.php sometimes gets overridden and getenvs are replaced with absolute values, which doesn't makes sense since those parameters are defined in env variables.
Maybe it's a good idea to chown local.php to developer:users as well?