Bug 584443
| Summary: | dmesg cannot print to console in single-user mode | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Schmidt <mschmidt> |
| Component: | selinux-policy | Assignee: | Daniel Walsh <dwalsh> |
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 13 | CC: | dwalsh, mgrepl, notting |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2010-06-29 15:35:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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 *** |
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?)