Bug 641153
| Summary: | Can't shutdown from Gnome | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Vaclav "sHINOBI" Misek <misek> |
| Component: | selinux-policy-targeted | Assignee: | Miroslav Grepl <mgrepl> |
| Status: | CLOSED NOTABUG | QA Contact: | Ben Levenson <benl> |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 14 | CC: | dwalsh, eparis |
| Target Milestone: | --- | Keywords: | Reopened |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2011-05-26 20:14:36 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: | |||
You should not have files labeled file_t on your machine, This means the file does not have a label. fixfiles restore Should clean these up. *** This bug has been marked as a duplicate of bug 537613 *** I already relabeled all system through "touch /.autorelabel; reboot" before I filled this bug, but for the piece of mind I ran "fixfiles restore". This command passed without errors, but after reboot it still persists. Should the problem be that I'm using BTRFS for root partition? The halt file shows: ls -laZ /sbin/halt lrwxrwxrwx. root root system_u:object_r:file_t:SystemLow /sbin/halt -> ../lib/upstart/reboot and even after restorecon /sbin/halt the label is the same. What does restorecon -n -v /sbin/halt do? No change, still the same label. And there is no error message. Shouldn't be anything wrong with btrfs and SELinux, I've been running it for a long long time. Only thing I notice is different than I'm used to is that you are running mcstransd, not sure how it could be related at all.... What does matchpathcon /sbin/halt give you? this is very odd. How about getfattr -n security.selinux /sbin/halt # matchpathcon /sbin/halt /sbin/halt system_u:object_r:bin_t:SystemLow # getfattr -n security.selinux /sbin/halt getfattr: Removing leading '/' from absolute path names # file: sbin/halt security.selinux="system_u:object_r:bin_t:s0 Ummm, getfattr shows one things but ls -lZ shows another, I'm very very confused. Can you confirm that ls -lZ shows file_t? Dan is there some way to verify if system_u:object_r:bin_t:s0 is valid on his system, or if mcstransd is mistranslating? Yup, the output is still the same: $ ls -lZ /sbin/halt lrwxrwxrwx. root root system_u:object_r:file_t:SystemLow /sbin/halt -> ../lib/upstart/reboot It's a little bit surprising to me as well. Should I try to remove mcstransd? service stop msctransd and then check. With msctransd stopped it looks still the same: # ls -laZ /sbin/halt lrwxrwxrwx. root root system_u:object_r:file_t:s0 /sbin/halt -> ../lib/upstart/reboot # getfattr -n security.selinux /sbin/halt getfattr: Removing leading '/' from absolute path names # file: sbin/halt security.selinux="system_u:object_r:bin_t:s0 Just for a test, if you execute # chcon -t user_home_t /lib/upstart/reboot # ls -lZ /sbin/halt Still the same. BTW /lib/upstart/reboot was/is labeled correctly # chcon -t user_home_t /lib/upstart/reboot # ls -lZ /sbin/halt lrwxrwxrwx. root root system_u:object_r:file_t:SystemLow /sbin/halt -> ../lib/upstart/reboot # getfattr -n security.selinux /sbin/halt getfattr: Removing leading '/' from absolute path names # file: sbin/halt security.selinux="system_u:object_r:user_home_t:s0 restorecon -R -v /sbin /lib/upstart getfattr -n security.selinux -h /sbin/halt (notice I added -h) # restorecon -R -v /sbin /lib/upstart restorecon reset /sbin/reload context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/restart context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/start context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/status context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/stop context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/halt context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/init context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/poweroff context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/reboot context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/runlevel context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/shutdown context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /sbin/telinit context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /lib/upstart/halt context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 restorecon reset /lib/upstart/poweroff context system_u:object_r:file_t:s0->system_u:object_r:bin_t:s0 # getfattr -n security.selinux -h /sbin/halt getfattr: Removing leading '/' from absolute path names # file: sbin/halt security.selinux="system_u:object_r:bin_t:s0 Hmmm now it looks the labels are correct. Any idea why fixfiles restore didn't work? |
Description of problem: My system doesn't shutdown from gnome or gdm. With setenforce 0 there is no problem and system shutdowns normally. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.9.5-9.fc14 How reproducible: Choose Shutdown from Gnome menu or GDM button. Actual results: kernel: type=1400 audit(1286484064.095:44687): avc: denied { read } for pid=27756 comm="ck-system-stop" name="shutdown" dev=sda3 ino=678550 scontext=system_u:system_r:consolekit_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=lnk_file Additional info: I tried to completely relabel my system, but with no success. This denial is not caught by setroubleshootd.