Thanks @RLazarus!

whether it's a good idea to support it at all

It's a way to communicate state to random parts of the codebase which are too deep in the call chain to reach normally via maintenance script parameters (in this case, some code in CommonSettings.php). Not sure if there's another use case (there's MW_LOG_STDERR but I think it doesn't work in the Wikimedia setup) but that one can be hard to avoid.

whether there need to be limits (do maintenance scripts still work properly if you pass an arbitrary value to $SERVER_NAME? what about $MW_INSTALL_PATH?)

You can definitely break maintenance scripts by changing the right env variable, but as long as the user needs to be explicit about which variables they want to set / copy, that seems like a "don't do that then" problem. From a security perspective, I don't think it makes any difference as you can already execute arbitrary code via shell.php (and mwscript also lets you run ad hoc PHP files).

In T380925#10360022, @Tgr wrote:

You can definitely break maintenance scripts by changing the right env variable, but as long as the user needs to be explicit about which variables they want to set / copy, that seems like a "don't do that then" problem. From a security perspective, I don't think it makes any difference as you can already execute arbitrary code via shell.php (and mwscript also lets you run ad hoc PHP files).

Yeah, I think this is right.

In T380925#10360022, @Tgr wrote:

(and mwscript also lets you run ad hoc PHP files).

For now. In mwscript-k8s, you can only run deployed files. Of course, barring social norms, nothing prevents deployers from deploying their ad hoc PHP files. The need of ad hoc maint scripts was discussed at T341553#10217538, there is T276994 for ad hoc PHP files on the web, but I can't find a task for ad hoc maintenance scripts.

In T380925#10362255, @Urbanecm_WMF wrote:

In mwscript-k8s, you can only run deployed files.

I never tried, but I assume you can just use --file?

In T380925#10362904, @Tgr wrote:

In T380925#10362255, @Urbanecm_WMF wrote:

In mwscript-k8s, you can only run deployed files.

I never tried, but I assume you can just use --file?

I never thought of (ab)using --file for this, as I think that was introduced for file-processing scripts like attachAccount.php, but it indeed seems to work:

[urbanecm@deploy2002 ~]$ cat test.php
<?php

$IP = getenv( 'MW_INSTALL_PATH' );
if ( $IP === false ) {
                $IP = __DIR__ . '/../../..';
}
require_once "$IP/maintenance/Maintenance.php";

class TestScript extends Maintenance {
        public function execute() {
                $firstUserName = User::newFromId(1)->getName();
                var_dump($firstUserName);
        }
}

$maintClass = TestScript::class;
require_once RUN_MAINTENANCE_IF_MAIN;
[urbanecm@deploy2002 ~]$ mwscript-k8s -f --file test.php /data/test.php -- --wiki=cswiki
⏳ Starting /data/test.php on Kubernetes as job mw-script.codfw.mvbf4wac ...
⏳ Waiting for the container to start...
🚀 Job is running.
📜 Streaming logs:
string(23) "Miroslav Malovec~cswiki"
[urbanecm@deploy2002 ~]$

I stand corrected – thank you!

(That said, I am wondering whether this works as a coincidence, or whether it was actually intended to behave this way.)

Change #1142794 had a related patch set uploaded (by RLazarus; author: RLazarus):

[operations/deployment-charts@master] mediawiki: Allow setting env variables in mw-script

https://gerrit.wikimedia.org/r/1142794

Change #1142795 had a related patch set uploaded (by RLazarus; author: RLazarus):

[operations/puppet@production] deployment_server: Add --env to mwscript-k8s

https://gerrit.wikimedia.org/r/1142795

Change #1142794 merged by jenkins-bot:

[operations/deployment-charts@master] mediawiki: Allow setting env variables in mw-script

https://gerrit.wikimedia.org/r/1142794

Change #1142795 merged by RLazarus:

[operations/puppet@production] deployment_server: Add --env to mwscript-k8s

https://gerrit.wikimedia.org/r/1142795