abrt version: 2.0.5 executable: /usr/bin/python hashmarkername: setroubleshoot kernel: 3.1.0-0.rc6.git0.3.fc16.x86_64 reason: SELinux is preventing /bin/dbus-daemon from 'read' accesses on the file /home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc. time: Tue Sep 20 21:32:10 2011 description: :SELinux is preventing /bin/dbus-daemon from 'read' accesses on the file /home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc. : :***** Plugin restorecon (99.5 confidence) suggests ************************* : :If you want to fix the label. :/home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc default label should be icc_data_home_t. :Then you can run restorecon. :Do :# /sbin/restorecon -v /home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc : :***** Plugin catchall (1.49 confidence) suggests *************************** : :If you believe that dbus-daemon should be allowed read access on the edid-f96117f183382b871c31aa58fdbe5297.icc file by default. :Then you should report this as a bug. :You can generate a local policy module to allow this access. :Do :allow this access for now by executing: :# grep dbus-daemon /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 :Target Context unconfined_u:object_r:user_home_t:s0 :Target Objects /home/ccc/.local/share/icc/edid- : f96117f183382b871c31aa58fdbe5297.icc [ file ] :Source dbus-daemon :Source Path /bin/dbus-daemon :Port <Unknown> :Host (removed) :Source RPM Packages dbus-1.4.10-3.fc16 :Target RPM Packages :Policy RPM selinux-policy-3.10.0-31.fc16 :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.1.0-0.rc6.git0.3.fc16.x86_64 #1 SMP : Fri Sep 16 12:26:22 UTC 2011 x86_64 x86_64 :Alert Count 1 :First Seen Tue 20 Sep 2011 09:24:34 PM CEST :Last Seen Tue 20 Sep 2011 09:24:34 PM CEST :Local ID 97ed55b0-8a7e-49e7-b5fa-5c00bc11d09a : :Raw Audit Messages :type=AVC msg=audit(1316546674.876:85): avc: denied { read } for pid=930 comm="dbus-daemon" path="/home/ccc/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc" dev=sda4 ino=2755380 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file : : :type=SYSCALL msg=audit(1316546674.876:85): arch=x86_64 syscall=recvmsg success=yes exit=401 a0=1d a1=7ffffb295170 a2=40000000 a3=0 items=0 ppid=1 pid=930 auid=4294967295 uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81 tty=(none) ses=4294967295 comm=dbus-daemon exe=/bin/dbus-daemon subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 key=(null) : :Hash: dbus-daemon,system_dbusd_t,user_home_t,file,read : :audit2allow : :#============= system_dbusd_t ============== :allow system_dbusd_t user_home_t:file read; : :audit2allow -R : :#============= system_dbusd_t ============== :allow system_dbusd_t user_home_t:file read; :
Why is the dbus-daemon reading this file? And who created these files. They are still mislabeled. Was this a fresh install or did you just update it?
Oh. Ahaa. I can reproduce this by rebooting and relabelling, enforcing mode, creating a new user on a tty while in gdm, log in as that user ... and boom, this avc and effectively Bug 738803. When I reproduce it with another new user without rebooting I see no problem. (When I login as my own user with home on (slow) nfs I see the problem every time ... unless I setenforce 0 ... but that might be a different issue.) BUT when I disable /etc/xdg/autostart/restorecond.desktop I can reproduce it with new accounts every time. They leave a lot of files incorrectly labelled - including: restorecon reset /home/zzz/.local/share/icc context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:icc_data_home_t:s0 restorecon reset /home/zzz/.local/share/icc/edid-f96117f183382b871c31aa58fdbe5297.icc context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:icc_data_home_t:s0 restorecon reset /home/zzz/.local/share/icc/edid-217b41bfa44c6012e3120b7588bf9d60.icc context unconfined_u:object_r:user_home_t:s0->unconfined_u:object_r:icc_data_home_t:s0 Is it some kind of race with restorecon? The global restorecond service is not enabled. Should it be that?
anything you had on the system prior to the -31 update won't get fixed by it. what was broken was a mechanism called 'filetrans' by which the kernel should apply correct labels to newly-created files and directories. it doesn't scan over *existing* ones and fix them. so files that got the wrong labels because they were created while selinux-policy was broken are going to _stay_ broken. in other words - it's expected that your regular user account will be broken. you'll have to do a 'restorecon -r ~/' to fix it. however, the case where you create a new user and their files are mislabelled is not expected, and sounds like filetrans still isn't working for you. we might need logs and stuff. I will see if I can recreate. please disable restorecond for testing; things should work without it, and having it enabled can mask the bug. we don't want to rely on restorecond to make this stuff work.
Adam, I'm not sure what you are telling me or what I can tell that I haven't told already: I relabeled-on-boot after installing -31, then I added the user and tried to login. restorecond.service wasn't running, and without autostart restorecond.desktop I saw mislabelled files every time - which hints that the reason that it sometimes works is that restorecond.desktop fixes the labels before any harm is done.
Well, then there is something wrong. I am pretty sure it was working. Mads, what does for you # sesearch -T -s sysadm_t -t admin_home_t
Actually this sesearch doesn't work for F16.
Ok, I got it. I need to rebuild checkpolicy. I use my own build which should be the same as the koji build but is not.
Mads, could you test it with these packages http://koji.fedoraproject.org/koji/taskinfo?taskID=3367584 http://koji.fedoraproject.org/koji/buildinfo?buildID=264786
+1 checkpolicy-2.1.3-1.2.fc16.x86_64 selinux-policy-targeted-3.10.0-32.fc16.noarch selinux-policy-3.10.0-32.fc16.noarch This and other problems seems to be gone now. Thanks!
selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/FEDORA-2011-13024
Package selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-32.fc16 checkpolicy-2.1.3-1.2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-32.fc16,checkpolicy-2.1.3-1.2.fc16 then log in and leave karma (feedback).
selinux-policy-3.10.0-32.fc16, checkpolicy-2.1.3-1.2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 752193 has been marked as a duplicate of this bug. ***
*** Bug 752194 has been marked as a duplicate of this bug. ***
Experiencing this problem starting yesterday [kevinj@raykj ~]$ rpm -q selinux-policy selinux-policy-3.10.0-51.fc16.noarch [kevinj@raykj ~]$ rpm -q kernel kernel-3.1.0-1.fc16.x86_64 kernel-3.1.0-5.fc16.x86_64 kernel-3.1.0-7.fc16.x86_64 SELinux is preventing /usr/libexec/colord from read access on the file /home/kevinj/.local/share/icc/edid-f33c31f22efffaff0b2bdf59439bb09e.icc. ***** Plugin restorecon (99.5 confidence) suggests ************************* If you want to fix the label. /home/kevinj/.local/share/icc/edid-f33c31f22efffaff0b2bdf59439bb09e.icc default label should be icc_data_home_t. Then you can run restorecon. Do # /sbin/restorecon -v /home/kevinj/.local/share/icc/edid-f33c31f22efffaff0b2bdf59439bb09e.icc ***** Plugin catchall (1.49 confidence) suggests *************************** If you believe that colord should be allowed read access on the edid-f33c31f22efffaff0b2bdf59439bb09e.icc file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # grep colord /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:colord_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:data_home_t:s0 Target Objects /home/kevinj/.local/share/icc/edid- f33c31f22efffaff0b2bdf59439bb09e.icc [ file ] Source colord Source Path /usr/libexec/colord Port <Unknown> Host raykj Source RPM Packages colord-0.1.13-2.fc16 Target RPM Packages Policy RPM selinux-policy-3.10.0-51.fc16 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name raykj Platform Linux raykj 3.1.0-7.fc16.x86_64 #1 SMP Tue Nov 1 21:10:48 UTC 2011 x86_64 x86_64 Alert Count 12 First Seen Wed 09 Nov 2011 04:15:51 PM EST Last Seen Thu 10 Nov 2011 07:51:26 AM EST Local ID b3f27e35-867e-4fd7-ab65-ca157f92c85a Raw Audit Messages type=AVC msg=audit(1320929486.41:77): avc: denied { read } for pid=1837 comm="colord" name="edid-f33c31f22efffaff0b2bdf59439bb09e.icc" dev=dm-3 ino=390180 scontext=system_u:system_r:colord_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:data_home_t:s0 tclass=file type=SYSCALL msg=audit(1320929486.41:77): arch=x86_64 syscall=open success=no exit=EACCES a0=70bf3a a1=0 a2=1b6 a3=0 items=0 ppid=1 pid=1837 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=colord exe=/usr/libexec/colord subj=system_u:system_r:colord_t:s0-s0:c0.c1023 key=(null) Hash: colord,colord_t,data_home_t,file,read audit2allow #============= colord_t ============== allow colord_t data_home_t:file read; audit2allow -R #============= colord_t ============== allow colord_t data_home_t:file read;
restorecon -R -v /home Should fix. Also yum -y update
I'm up to date on all my packages, have been since release day. I see that will "fix" it but not sure why all the sudden this was a problem. It did prevent login to gnome3 UI for a while -- I ended up having to go to VT to run the restorecon to fix
On upgrade the file was label in users homedirs was not fixed. Once you fix the label everything should be fine.