nixos/nextcloud: nextcloud-occ no longer works with envvars

[eyJhb]

Nixpkgs version

• Stable (25.05)

Describe the bug

There are some commands in nextcloud-occ, that can read from a envvar, such as nextcloud-occ user:resetpassword --password-from-env -- root, however it seems like #367433 might have changed that, and now clears all user envvars set.

Steps to reproduce

export OC_PASS="something"
nextcloud-occ user:resetpassword --password-from-env -- root

Gives the following error:

--password-from-env given, but OC_PASS is empty!

Expected behaviour

That it is possible to pass the password through envvars.

Screenshots

No response

Relevant log output

Additional context

No response

System metadata

 - system: `"x86_64-linux"`
 - host os: `Linux 6.12.30, NixOS, 25.05 (Warbler), 25.05pre-git`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.28.3`
 - channels(root): `"nixos-24.05"`
 - nixpkgs: `/nix/store/6n9f0nw4wyzmc4dg1lzxrmyca4j57zac-nixos-24.05/nixos`

Notify maintainers

@Ma27 @networkException

---

Note for maintainers: Please tag this issue in your pull request description. (i.e. Resolves #ISSUE.)

I assert that this issue is relevant for Nixpkgs

• I assert that this is a bug and not a support request.
• I assert that this is not a duplicate of an existing issue.
• I assert that I have read the NixOS Code of Conduct and agree to abide by it.

Is this issue important to you?

Add a 👍 reaction to issues you find important.

[Ma27]

I assume you've done this before as nextcloud user? Because otherwise you would've used the old sudo code-path which also cleans out all of the env (no -E).

I think we could fix that by doing -p Environment="$OC_PASS" in the script, but this kinda depends on how many other variables are theoretically needed to be passed through. On top of that, I'm not a big fan of that approach anyways: the snippet above invites to forget about unsetting the env after that and every invocation down the road also knows about the password (so yeah, handling secrets via env is problematic).

cc @networkException @provokateurin for opinions.

[eyJhb]

I've done this as part of the nextcloud-setup systemd service, which runs as nextcloud:

nixpkgs/nixos/modules/services/web-apps/nextcloud.nix

Line 1232 in 4792576

serviceConfig.User = "nextcloud";

Example of what I have done in the past is here:

• https://git.fricloud.dk/fricloud/server-configs/src/commit/038865ba84cefc389947b0b7a115c2c0954650e5/machines/gerd/services/nextcloud.nix#L92-L97
• https://git.fricloud.dk/fricloud/server-configs/src/commit/038865ba84cefc389947b0b7a115c2c0954650e5/machines/gerd/services/nextcloud.nix#L199-L218

Either way, it's now impossible to use any command that would benefit from a envvar, no matter how nextcloud-occ is called, which seems inconvenient, as it's meant to be run by a system administrator as well.

I'm however not sure what a "good" solution would be for this,

I'm not a big fan of that approach anyways: the snippet above invites to forget about unsetting the env after that and every invocation down the road also knows about the password (so yeah, handling secrets via env is problematic).

It's a standalone script, so it's not really a worry in this case, and it's just one use-case that I have. Others might have better ones.

[Ma27]

So the use-case around this is to make sure that the root user's password is always in sync with what the config says?

which seems inconvenient, as it's meant to be run by a system administrator as well.

yeah, though I'm not aware of anything else that actually needs environment variables. And this use-case never worked before unless you were running as Nextcloud user. The sudo-invocation already filtered out env vars before.

It's a standalone script, so it's not really a worry in this case, and it's just one use-case that I have. Others might have better ones.

That's fair. It wasn't clear to me how this was actually used from the first report and it looked a bit like something, that was intended to be used in an interactive shell.

But yeah, I'm not sure right now. We could probably fix it by injecting OC_PASS everywhere, but this is something I'd like to have a regression test for that and I'd like to have ruled out that we'll have to add 23 additional env vars down the road.

Hence, I'd like to wait for more input first.

[eyJhb]

Luckily there doesn't seem to be many cases of envvars in occ command, at least a basic grep gives this:

> grep -r1 'getenv('
Command/User/ResetPassword.php-         if ($input->getOption('password-from-env')) {
Command/User/ResetPassword.php:                 $password = getenv('OC_PASS');
Command/User/ResetPassword.php-                 if (!$password) {
--
Command/User/AuthTokens/Add.php-                if ($input->getOption('password-from-env')) {
Command/User/AuthTokens/Add.php:                        $password = getenv('NC_PASS') ?? getenv('OC_PASS');
Command/User/AuthTokens/Add.php-                        if (!$password) {
--
Command/User/Add.php-           if ($input->getOption('password-from-env')) {
Command/User/Add.php:                   $password = getenv('OC_PASS');
Command/User/Add.php-

So, it's OC_PASS and NC_PASS, which seems quite minimal :) There are some others outside of the core folder, but not too many.

But another thing that's annoying, is that it's not really intuitive that the command is filtering out the env. The only way to discover it is to inspect the bin, if you think of that.

[networkException]

I think something like this is the only sensible way forward, yes. I'm not sure wehter to use -p Environment or --setenv here though, the latter seems to set [ON]C_PASS to an empty string unconditionally

ff --git a/nixos/modules/services/web-apps/nextcloud.nix b/nixos/modules/services/web-apps/nextcloud.nix
index 6f92c0ca5e58..dedd193ec803 100644
--- a/nixos/modules/services/web-apps/nextcloud.nix
+++ b/nixos/modules/services/web-apps/nextcloud.nix
@@ -165,19 +165,25 @@ let
             --wait \
             --collect \
             --service-type=exec \
+            --setenv OC_PASS \
+            --setenv NC_PASS \
             --quiet \
             ${command}
         elif [[ "$USER" != nextcloud ]]; then
           if [[ -x /run/wrappers/bin/sudo ]]; then
             exec /run/wrappers/bin/sudo \
               --preserve-env=CREDENTIALS_DIRECTORY \
+              --preserve-env=OC_PASS \
+              --preserve-env=NC_PASS \
               --user=nextcloud \
               ${command}
           else
             exec ${lib.getExe' pkgs.util-linux "runuser"} \
               --whitelist-environment=CREDENTIALS_DIRECTORY \
+              --whitelist-environment=OC_PASS \
+              --whitelist-environment=NC_PASS \
               --user=nextcloud \
-              ${command}
+              -- ${command}
           fi
         else
           exec ${command}

[provokateurin]

Luckily there doesn't seem to be many cases of envvars in occ command

Unfortunately this is not true, as any system (config.php) option can be set through env vars with NC_ prefix: https://github.com/nextcloud/server/blob/f25d66008b7af7291b78521708f76bc9da6f2365/lib/private/Config.php#L249-L258

On top of that, I'm not a big fan of that approach anyways

I fully agree. It should also be possible to pipe the password to the occ command (and I suppose this will work in any place where a value is taken from stdin or env).

[networkException]

Unfortunately this is not true, as any system (config.php) option can be set through env vars with NC_ prefix

Is that relevant to invocations of occ?

[provokateurin]

Yes, for example you could change the log level when invoking occ commands for debugging. So it should be either none or all config values that are configurable through the env vars.

[eyJhb]

We might disagree with how it's done upstream, but at this point we're just breaking occ in a not very intuitive way.
What is the reason for clearing the env before invoking occ?

[Ma27]

This only ever worked as nextcloud user because the sudo-invocation existed before already.

sudo clears the env by default. And systemd-run creates a transient unit that doesn't inherit the env from the shell, but from its the service manager.

[provokateurin]

I'm running into this problem as well now, as I need to write a NixOS test that invokes nextcloud-occ user:add --password-from-env. There is no other way to do this right now.
I would be in favor of applying the changes from @networkException #412675 (comment) as a workaround for now and then we can find a better solution for the future.