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