Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 584443 - dmesg cannot print to console in single-user mode
Summary: dmesg cannot print to console in single-user mode
Status: CLOSED DUPLICATE of bug 540216
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 13
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2010-04-21 15:19 UTC by Michal Schmidt
Modified: 2010-06-29 15:35 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-06-29 15:35:28 UTC
Type: ---

Attachments (Terms of Use)

Description Michal Schmidt 2010-04-21 15:19:45 UTC
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 15:22:38 UTC
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 15:29:39 UTC
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 16:42:13 UTC
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 16:43:49 UTC
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 17:10:02 UTC
Would this be 'fixed' by using sulogin?

Comment 6 Daniel Walsh 2010-04-21 17:34:16 UTC

Comment 7 Bill Nottingham 2010-06-29 15:35:28 UTC

*** 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.