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