Summary: SELinux is preventing the /bin/loadkeys from using potentially mislabeled files (Documents). Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux has denied loadkeys access to potentially mislabeled file(s) (Documents). This means that SELinux will not allow loadkeys to use these files. It is common for users to edit files in their home directory or tmp directories and then move (mv) them to system directories. The problem is that the files end up with the wrong file context which confined applications are not allowed to access. Allowing Access: If you want loadkeys to access this files, you need to relabel them using restorecon -v 'Documents'. You might want to relabel the entire directory using restorecon -R -v 'Documents'. Additional Information: Source Context unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c102 3 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects Documents [ dir ] Source loadkeys Source Path /bin/loadkeys Port <Unknown> Host (removed) Source RPM Packages kbd-1.15-9.fc12 Target RPM Packages Policy RPM selinux-policy-3.6.32-24.fc12 Selinux Enabled True Policy Type targeted MLS Enabled True Enforcing Mode Permissive Plugin Name home_tmp_bad_labels Host Name (removed) Platform Linux (removed) 2.6.31.1-56.fc12.i686 #1 SMP Tue Sep 29 16:32:02 EDT 2009 i686 athlon Alert Count 2 First Seen Wed 21 Oct 2009 04:09:19 AM CEST Last Seen Wed 21 Oct 2009 04:09:19 AM CEST Local ID 40afda63-b9d7-4be8-9866-c97bdc442298 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1256090959.940:31037): avc: denied { read } for pid=2400 comm="loadkeys" name="Documents" dev=dm-0 ino=92322 scontext=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir node=(removed) type=AVC msg=audit(1256090959.940:31037): avc: denied { open } for pid=2400 comm="loadkeys" name="Documents" dev=dm-0 ino=92322 scontext=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1256090959.940:31037): arch=40000003 syscall=5 success=yes exit=6 a0=80568e7 a1=98800 a2=80568e7 a3=bf8cfcd1 items=0 ppid=2258 pid=2400 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=1 comm="loadkeys" exe="/bin/loadkeys" subj=unconfined_u:unconfined_r:loadkeys_t:s0-s0:c0.c1023 key=(null) Hash String generated from selinux-policy-3.6.32-24.fc12,home_tmp_bad_labels,loadkeys,loadkeys_t,user_home_t,dir,read audit2allow suggests: #============= loadkeys_t ============== allow loadkeys_t user_home_t:dir { read open };
What were you doing when you got this AVC to happen?
This bug emerged right after F12-Beta-i686-Live-KDE.iso (burned to CD) booted to KDE. I was doing "nothing". Previous version I tried (I think it was Beta RC2 from 2009-10-15 was ok).
When you login, what does id -Z show?
I tried it again and I can't reproduce it now :( [liveuser@localhost ~]$ id -Z unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Well since it makes no sense at all, I will just close it as worksforme. If you can reproduce, reopen it. Thanks.
It just occurred here when installing from the KDE Live CD F12 beta i386. It happened once it was setting the permissions on the filesystem after copying the image over. Reopening.
Did you get the same avc? Could you attach your /var/log/audit/audit.log? I can not see why the load_keys program would be trying to read the contents of the Documents directory under a users homedir.
The bug reporting tool came up with this bug report as a duplicate, so I assume it is the same denial. This bug actually happened on a friend's machine while installing, I entered my information to report the bug so that it got reported. I'll get him CC'd to get more information.
Blocking F12Blocker (KDE-SIG meeting).
The impact of this bug isn't at all clear, from the descriptions above you get a denial but nothing seems to suggest this breaks anything. Could you explain more clearly what the problem is here? I do catch a reference to '"install to hd link on desktop lacking execute permission" problem' in the KDE meeting log, but that's a bit cryptic with no context. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I would agree, in retrspect, that without knowing the impact here, it's premature to consider this a blocker. removing, until we have further data.
it's obviously not nice from a polish perspective, but we're right down to the wire for f12 final (we basically have today and tomorrow to fix blockers) so i have a pretty high bar on new blocker issues right now :/ -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
The .desktop file lacking execute permission is a completely separate issue.
Thanks for that clarification. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I am allowing it in selinux-policy-3.6.32-41.fc12.noarch Just for polish reasons. But will remove from Rawhide after F12 ships, since I think this is covering up a bug.
it may help the KDE folks fix it properly if you could provide a hint about what you think the bug is - I guess "I can not see why the load_keys program would be trying to read the contents of the Documents directory under a users homedir." ? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle. Changing version to '13'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This looks like a duplicate of Bug 519709 for which an upstream fix has been committed. This will probably be fixed in the next release of livecd-tools.
livecd-tools-034-1.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/livecd-tools-034-1.fc14
livecd-tools-034-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update livecd-tools'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/livecd-tools-034-2.fc14
livecd-tools-034-7.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/livecd-tools-034-7.fc14
livecd-tools-034-7.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update livecd-tools'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/livecd-tools-034-7.fc14
livecd-tools-034-7.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.