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

Hi Christian,

* Christian Albrecht Goeschel Ndjomouo <[email protected]> [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