Bug 584443 - dmesg cannot print to console in single-user mode
dmesg cannot print to console in single-user mode
Status: CLOSED DUPLICATE of bug 540216
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-04-21 11:19 EDT by Michal Schmidt
Modified: 2010-06-29 11:35 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-06-29 11:35:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Michal Schmidt 2010-04-21 11:19:45 EDT
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):

How reproducible:

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"):
(Isn't it supposed to be unconfined_t too as in normal runlevels? Whose bug would that be? upstart? initscripts?)
Comment 1 Michal Schmidt 2010-04-21 11:22:38 EDT
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;
Comment 2 Michal Schmidt 2010-04-21 11:29:39 EDT
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)
Comment 3 Daniel Walsh 2010-04-21 12:42:13 EDT
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.

Comment 4 Daniel Walsh 2010-04-21 12:43:49 EDT
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.
Comment 5 Bill Nottingham 2010-04-21 13:10:02 EDT
Would this be 'fixed' by using sulogin?
Comment 6 Daniel Walsh 2010-04-21 13:34:16 EDT
Comment 7 Bill Nottingham 2010-06-29 11:35:28 EDT

*** This bug has been marked as a duplicate of bug 540216 ***

Note You need to log in before you can comment on or make changes to this bug.