After upgrading to selinux-policy-targeted-3.11.1-57.fc18 , suddenly I can't access a drive I have mounted at /media/Sea500 , which is a general storage drive, contains no system stuff. I've just created files on it with normal applications, mkdir, wget and so on. I've never had any problem accessing it before, but suddenly, when I do ls /media/Sea500 , I get this: [root@adam x86_64]# ls /media/Sea500/ ls: cannot access /media/Sea500/images: Permission denied ls: cannot access /media/Sea500/lost+found: Permission denied images lost+found and I can't see or use anything inside /media/Sea500/images (where I keep all my Fedora ISOs). 'setenforce Permissive' 'fixes' it. In /var/log/messages I see a bunch of this kinda thing: Nov 30 14:07:37 adam setroubleshoot: SELinux is preventing /usr/bin/bash from getattr access on the directory /media/Sea500/images. For complete SELinux messages. run sealert -l 7a65d862-312a-4f92-9bc2-4383e0d8ebf5 Nov 30 14:07:37 adam sedispatch: AVC Message for setroubleshoot, dropping message Nov 30 14:07:38 adam sedispatch: AVC Message for setroubleshoot, dropping message Nov 30 14:07:38 adam setroubleshoot: SELinux is preventing /usr/bin/ls from getattr access on the directory /media/Sea500/lost+found. For complete SELinux messages. run sealert -l 92013133-cde0-4082-99a9-54797da0abf3 I'll attach the sealert output. 'restorecon -nvr' doesn't want to change anything, if I try that.
Created attachment 655296 [details] sealert output
I have similar symptoms. My machine has two disk drives. I have an ext4 partition on the larger slower one mounted on '/data' on the smaller faster one. Everything's been working fine but after a recent update, I couldn't do an 'ls' or 'getattr' on the partition. I ended up editing /etc/sysconfig/selinux and changing SELINUX from 'enforcing' to 'disabled'.
borasky: usually there's no need to disable selinux entirely, you can just set it to permissive mode, where policy infringements are reported but allowed. You can do that on the fly without rebooting: just do 'setenforce Permissive' as root. Works for this case. It's faster and doesn't need a policy rebuild when you go back to enforcing ('setenforce Enforcing').
Same issue here SELinux is preventing /usr/libexec/gvfsd-trash from read access on the directory /. Additional Information: Source Context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1 023 Target Context system_u:object_r:file_t:s0 Target Objects / [ dir ] Source gvfsd-trash Source Path /usr/libexec/gvfsd-trash Port <Unknown> Host localhost Source RPM Packages gvfs-1.14.2-1.fc18.x86_64 Target RPM Packages filesystem-3.1-2.fc18.x86_64 Policy RPM selinux-policy-3.11.1-57.fc18.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost Platform Linux localhost 3.6.7-5.fc18.x86_64 #1 SMP Tue Nov 20 19:40:08 UTC 2012 x86_64 x86_64 Alert Count 296 First Seen 2012-12-01 23:26:13 IST Last Seen 2012-12-02 00:19:42 IST Local ID b6197d79-d957-4967-b19a-11892f79c481 Raw Audit Messages type=AVC msg=audit(1354387782.707:406): avc: denied { read } for pid=1832 comm="gvfsd-trash" name="/" dev="sda2" ino=2 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir type=SYSCALL msg=audit(1354387782.707:406): arch=x86_64 syscall=inotify_add_watch success=no exit=EACCES a0=6 a1=21066c0 a2=1002fce a3=1 items=0 ppid=1 pid=1832 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm=gvfsd-trash exe=/usr/libexec/gvfsd-trash subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) Hash: gvfsd-trash,unconfined_t,file_t,dir,read -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
That does not look like the same issue. It's not 'bash' or 'ls', and it is requesting access to a system directory - root, in fact - not to a storage drive.
Created attachment 655698 [details] Video description
well i saw the AVC denial after i created a new ext4 partition and was trying to mount the volume as described in video
Adam, I have been getting numerous SELinux denials since the last update to 3.11.1-57. At first I thought maybe my filesystem just needed to be relabelled like has happened a few times in pre-release versions on policy updates, so I did a relabel. I did get a few messages during the relable, too. SELinux: Context system_u:object_r:consolekit_exec_t:s0 is not valid (left unmapped) SELinux: Context system_u:object_r:consolekit_unit_file:s0 is not valid (left unmapped) and one other one pertaining same as above pertaining to consolekit_log something or other, I missed the entire message. But ever since the update, I have been getting numerous denials in gvfs-trash, lost+found, when lightdm starts (probably related to the consolekit messages above) and random other places as well. I don't know what they changed in the 3.11.1-57 policy, but it broke numerous things here.
I'm still trying to figure out why it's failing on one machine but not on another. The one that works has /data and the partition mounted on /data on the same drive. The one that fails has /data on one drive and the partition mounted on /data on another drive. That's the only obvious difference.
Created attachment 655766 [details] Some of the denials I have been getting (From audit.log)
Well selinux policy targeted 3.11.1-59 fixed my ConsoleKit problems, but the denials for lost+found and even some of my bash script files are still occurring. downgrading selinux policy to 3.11.1.50 fixes all of my issues.
*** This bug has been marked as a duplicate of bug 882255 ***