On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote: > 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. > > 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 Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selinux-policy.spec#n173 https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selinux-policy.spec#n393 I vaguely recall that in a strict environment one still might need run_init for the `update aliases` functionality in redhar-based distributions.. i might be wrong though > 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. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift
Attachment:
signature.asc
Description: PGP signature
