Le 26/06/17 à 15:08, Stephen Smalley a écrit :
On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote:
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
I don't think this could have ever worked under run_init since
open_init_pty was introduced (originally from Debian); note that
open_init_pty does alter terminal settings.
I don't quite follow the example given above. It shows executing
run_init twice with ls /boot as the arguments, which is not running
run_init within run_init. That works fine for me.
I just re-tried again and I can definitely reproduce this in debian
unstable. My complete test case is:
sudo -i
<type the password>
run_init ls /boot
<type the password>
<ls output>
run_init ls /boot
<error>
If I exit the shell started by sudo, run_init will works again for one
invocation before getting the error again.
If I try something like:
run_init run_init ls /boot
which actually runs run_init within run_init, then that also works for
me without problem.
If I try something like:
run_init /bin/bash
then I lose any echoing of input characters to the shell (due to
open_init_pty turning it off), but I can enter commands and execute
them, or run stty sane to regain echoing. But I don't think that has
ever been supported since the introduction of open_init_pty in 2005
(policycoreutils 1.21.2). What's the use case for it?
Side bar: run_init (and open_init_pty) are no longer packaged by Fedora
since systemd renders it unnecessary, and even prior to that, Fedora
policy enabled DIRECT_INITRC=y in build.conf, and therefore run_init
wasn't required for typical operation (maybe under -mls policy it was
still needed, not sure). Possibly we should move run_init out of
policycoreutils into its own subdirectory in the selinux userspace tree
to reflect this transition and start deprecating it.
run_init and newrole executables are still packaged in debian but in a
different package that is not pulled by anything, so people that need it
have to manually install it.
