Description of problem: When the system is booted into single-user mode (using the 'single' boot parameter) or into runlevel 1, dmesg is unable to print anything to the console. Using redirection it is however possible to get its output. Version-Release number of selected component (if applicable): util-linux-ng-2.17.2-3.fc13.x86_64 selinux-policy-targeted-3.7.19-2.fc13.noarch How reproducible: always Steps to Reproduce: 1. Switch to runlevel 1: init 1 2. dmesg Actual results: No output produced. "dmesg|cat" would work though. Expected results: dmesg should produce output to the console. Additional info: Using strace I observed that the dmesg process's stdout gets redirected to /dev/null as proved by this line: fstat(1, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0 (Character device 1:3 is /dev/null). It works fine in permissive mode. When run in permissive mode, dmesg's stdout corresponds to /dev/console: fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(5, 1), ...}) = 0 Root's shell in single-user mode (and in runlevel 1) runs in the SELinux context (as shown by "id -Z"): system_u:system_r:initrc_t:s0 (Isn't it supposed to be unconfined_t too as in normal runlevels? Whose bug would that be? upstart? initscripts?)
By disabling dontaudit rules (semodule -R -B -D) I got the relevant AVC denial. "audit2allow -d" says: allow dmesg_t console_device_t:chr_file read;
For completeness here's the raw denial and audit message: type=1400 audit(1271863423.995:231): avc: denied { read } for pid=1117 comm="dmesg" name="console" dev=devtmpfs ino=4530 scontext=system_u:system_r:dmesg_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file type=1300 audit(1271863423.995:231): arch=c000003e syscall=59 success=yes exit=0 a0=f5f6e0 a1=f5f780 a2=f41e00 a3=10 items=0 ppid=1082 pid=1117 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=tty1 ses=4294967295 comm="dmesg" exe="/bin/dmesg" subj=system_u:system_r:dmesg_t:s0 key=(null)
dmesg | cat Would work. The problem is when we login at Single User mode we are loggin in as initrc_t since this is the context of shells launched by /sbin/init. If you were to execute sulogin, you will transition to unconfined_t. And everything should work ok. dmesg
Bill, I guess we need to come to some conclusion on this. Could we have init always execute a particular shell when entering Single user mode? If we did this I could execute a transition to unconfined_t or sysadm_t.
Would this be 'fixed' by using sulogin?
yes
*** This bug has been marked as a duplicate of bug 540216 ***