Re: Bug#1132588: runuser: missing whitelist-environment option

Re: Bug#1132588: runuser: missing whitelist-environment option

[Chris Hofstaedtler]

[CC'ing upstream]

On Fri, Apr 03, 2026 at 11:57:46AM +0200, Katie May wrote:
> Package: util-linux
> Version: 2.42-1
> 
> Dear Maintainer,
> 
> runuser no longer accepts the whitelist-environment option (both in long
> and short form) despite it still being listed in the man page.
> 
> For example, without specifying whitelist, runuser works
> ```
> # runuser -l test -c id
> uid=12345(test) gid=12345(test) groups=12345(test)
> ```
> 
> But if I specify an environment variable to whitelist I get an error
> ```
> # runuser -l test -w MY_VAR -c id
> -sh: 0: Illegal option -w
> ```

It appears to work when placing the options in a different order, 
f.e. this works:

  # MY_VAR=foo runuser -w MY_VAR -l root -c env

Notably the placement of the -l option and the username seem to be 
the problem.

I'll note that `MY_VAR=foo runuser -l root -w MY_VAR -c env` worked in 2.41.

Maybe ac0147fd14b348097c82c1c89a5417b582e26bad broke this?

| commit ac0147fd14b348097c82c1c89a5417b582e26bad
| Author:     cgoesche <cgoesc2@wgu.edu>
| AuthorDate: Sun Nov 2 11:55:09 2025 -0500
| Commit:     cgoesche <cgoesc2@wgu.edu>
| CommitDate: Mon Nov 3 13:16:19 2025 -0500
| 
|     su: pass arguments after <user> to shell
| 
|     The su(1) manpage describes how the arguments after <user>
|     are passed to the invoked shell. However this is empirically
|     wrong, as option flags after <user> are interpreted by su(1)
|     and will eventually never be passed or yield an error that
|     terminates the program due to an unrecognized option flag.
| 
|     To fix this we can change getopt(3)'s scanning mode with a '+'
|     prefixed to 'optstring', this will make it so that getopt(3)
|     stops processing argv elements on the first occurrence of a
|     non-option argument, e.g. '-' or '<user>'.
| 
|     Additionally, if the argument that directly follows '-' is an
|     option flag, su(1) will assume that this argument and the ones
|     that follow, are to be passed to a shell invoked by the root user.
| 
|     Addresses: https://github.com/util-linux/util-linux/pull/1809
|     Signed-off-by: cgoesche <cgoesc2@wgu.edu>


Chris

Re: Bug#1132588: runuser: missing whitelist-environment option

[Christian Albrecht Goeschel Ndjomouo]

Hey Chris,

The issue is indeed caused by the mentioned commit ac0147f, however
the change is necessary for proper functioning of su(1). Nevertheless, I
have created a PR that separates the short option strings used for su(1)
and runuser(1) as we need a different scanning mode for the former.

I have also added regression tests for runuser(1) and slightly improved
the one for su(1) so we can catch regressions earlier.

With the patch the issue with runuser should be fixed. Can you please
validate this ?

PR: https://github.com/util-linux/util-linux/pull/4185

Edit:

After taking a closer look at the runuser(1) man page it seems to me that
the actual documented syntax implies that options should always be put
before the username and potential arguments that are to be passed to the
shell or defined command. This aligns with the usage of su(1) and seems
more coherent. Let's see what Karel thinks about this :D

Regards,

Christian Goeschel Ndjomouo

Re: Bug#1132588: runuser: missing whitelist-environment option

[Chris Hofstaedtler]

Hi Christian,

* Christian Albrecht Goeschel Ndjomouo <cgoesc2@wgu.edu> [260404 01:25]:
>The issue is indeed caused by the mentioned commit ac0147f, however
>the change is necessary for proper functioning of su(1). Nevertheless, I
>have created a PR that separates the short option strings used for su(1)
>and runuser(1) as we need a different scanning mode for the former.
>
>I have also added regression tests for runuser(1) and slightly improved
>the one for su(1) so we can catch regressions earlier.

About su(1), in the meantime a Debian user filed a bug that su(1) 
regressed, too: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1132610
To quote:

| The command 'su <user> -s /bin/sh -c "echo foo"' now runs
| 'bash -s /bin/sh -c "echo foo"' instead of just
| '/bin/sh -c "echo foo"', which causes bash to hang reading commands
| from stdin.
| 
| This breaks suspend via in my setup which uses
| /usr/share/acpi-support/screenblank from the acpi-support package:
| 
|        if pidof xscreensaver >/dev/null; then
|                su "$XUSER" -s /bin/sh -c "xscreensaver-command -throttle"
|        fi

And:

| Actually the su man page says:
| 
| SYNOPSIS
|       su [options] [-] [user|UID [argument...]]
| 
| So one could argue that the acpi-support script's use of
| 'su "$XUSER" -s /bin/sh -c "..."' is buggy.
| 'su -s /bin/sh "$XUSER" -c "..."' works.
| 
| However, the acpi-support scripts (/usr/share/acpi-support/screenblank
| and /etc/acpi/lid.sh, have not checked others) worked with previous versions
| of util-linux.

It would seem that various versions of passing the command to su(1) 
are in use, and constraining them will break all these usages.

>With the patch the issue with runuser should be fixed. Can you please
>validate this ?
>
>PR: https://github.com/util-linux/util-linux/pull/4185
>
>Edit:
>
>After taking a closer look at the runuser(1) man page it seems to me that
>the actual documented syntax implies that options should always be put
>before the username and potential arguments that are to be passed to the
>shell or defined command. This aligns with the usage of su(1) and seems
>more coherent. Let's see what Karel thinks about this :D

I only had a quick look at runuser --help and the man page, and 
while it seems to imply that "-" and "-l" are supposed to do the 
same thing, I doubt this is what was intended and/or the actual
implementation.

At this point I also doubt that even if the documentation supports 
the new behaviour it's worth breaking all the existing users.

Chris

Re: Bug#1132588: runuser: missing whitelist-environment option

[Karel Zak]

On Sat, Apr 04, 2026 at 01:19:39PM +0200, Chris Hofstaedtler wrote:
> At this point I also doubt that even if the documentation supports the new
> behaviour it's worth breaking all the existing users.

I share the same view. We really don't want regressions that force
users to rewrite their scripts.

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com