Tested on Debian Buster. Seems to only happen on a fat client with some shells. On thin clients, it simply fails to log in. Possibly related to:
https://bugs.debian.org/490897
Confirmed behavior logging in as root:
fish, tcsh, csh
Following shells log in as the correct user:
zsh, dash, /bin/sh (as dash), bash, mksh, ksh
Login hangs due to some unrelated problem:
sash
With some shells, the LDM_USERNAME environment variable remains unset, and so in /usr/share/ldm/rc.d/X95-run-x-session ends up calling:
su - ${LDM_USERNAME} ...
And ends up as root.
The quick fix would be to check if LDM_USERNAME is set and at least error out if so, rather than granting root.
Still would be better to identify exactly where in the code we're expecting LDM_USERNAME to be set and fix it or error out there.
live well, vagrant
Tested on Debian Buster. Seems to only happen on a fat client with some
shells. On thin clients, it simply fails to log in. Possibly related to:
https:/ /bugs.debian. org/490897
Confirmed behavior logging in as root:
fish, tcsh, csh
Following shells log in as the correct user:
zsh, dash, /bin/sh (as dash), bash, mksh, ksh
Login hangs due to some unrelated problem:
sash
With some shells, the LDM_USERNAME environment variable remains unset, ldm/rc. d/X95-run- x-session ends up calling:
and so in /usr/share/
su - ${LDM_USERNAME} ...
And ends up as root.
The quick fix would be to check if LDM_USERNAME is set and at least
error out if so, rather than granting root.
Still would be better to identify exactly where in the code we're
expecting LDM_USERNAME to be set and fix it or error out there.
live well,
vagrant