Hello,
Russell opened the following bug regarding run_init in the debian
bts:
====
[...]
It turns out that the problem was not running $(arch), but running run_init in
the shell it spawned. Below is an example of reproducing this, the first time
run_init performs as expected. The second time is fails without me even
typing a password or pressing ENTER. The result is the same with any command,
but ls is just a good example. This happens no matter what shell is spawned
(whether it's ssh, su, or just an Xterm), run_init seems generally broken with
the 4.9.0-2-amd64/4.9.13-1 kernel at least.
NB I can't rule out the possibility of a kernel bug at this stage. But at
this time it seems best to assume it's a run_init bug until proven otherwise.
Sorry for the inconvenience Andreas.
# run_init ls /boot
Authenticating root.
Password:
config-4.9.0-2-amd64 lost+found System.map-4.9.0-3-amd64
config-4.9.0-3-amd64 memtest86+.bin vmlinuz-4.9.0-2-amd64
grub memtest86+_multiboot.bin vmlinuz-4.9.0-3-amd64
initrd.img-4.9.0-2-amd64 real
initrd.img-4.9.0-3-amd64 System.map-4.9.0-2-amd64
# run_init ls /boot
Authenticating root.
Password:
run_init: incorrect password for root
authentication failed.
#
====
I can reproduce this with 2.7-rc3, run_init is compiled with pam
and audit support.
An idea what could happen here?
Regards,
Laurent Bigonville
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187
