Summary: SELinux is preventing /usr/libexec/gsd-datetime-mechanism "getattr" access on /home/fedora/lib64. Detailed Description: [SELinux is in permissive mode. This access was not denied.] SELinux denied access requested by gsd-datetime-me. It is not expected that this access is required by gsd-datetime-me and this access may signal an intrusion attempt. It is also possible that the specific version or configuration of the application is causing it to require additional access. Allowing Access: You can generate a local policy module to allow this access - see FAQ (http://docs.fedoraproject.org/selinux-faq-fc5/#id2961385) Please file a bug report. Additional Information: Source Context system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects /home/fedora/lib64 [ dir ] Source gsd-datetime-me Source Path /usr/libexec/gsd-datetime-mechanism Port <Unknown> Host (removed) Source RPM Packages gnome-settings-daemon-2.32.0-2.fc14 Target RPM Packages Policy RPM selinux-policy-3.9.7-10.fc14 Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Plugin Name catchall Host Name (removed) Platform Linux (removed) 2.6.35.8-59.fc14.x86_64 #1 SMP Tue Nov 16 03:32:03 UTC 2010 x86_64 x86_64 Alert Count 1 First Seen Tue 16 Nov 2010 04:03:04 PM CET Last Seen Tue 16 Nov 2010 04:03:04 PM CET Local ID b336e51d-1776-4a1b-972d-31a933c61de4 Line Numbers Raw Audit Messages node=(removed) type=AVC msg=audit(1289919784.243:31432): avc: denied { getattr } for pid=2881 comm="gsd-datetime-me" path="/home/fedora/lib64" dev=dm-2 ino=3407980 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir node=(removed) type=SYSCALL msg=audit(1289919784.243:31432): arch=c000003e syscall=4 success=yes exit=0 a0=7fffe111e5d0 a1=7fffe111e690 a2=7fffe111e690 a3=ffffffff items=0 ppid=2880 pid=2881 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gsd-datetime-me" exe="/usr/libexec/gsd-datetime-mechanism" subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null) Hash String generated from catchall,gsd-datetime-me,gnomeclock_t,user_home_t,dir,getattr audit2allow suggests: #============= gnomeclock_t ============== allow gnomeclock_t user_home_t:dir getattr;
This looks like you have some kind of strange setup? Why is there a /lib64 sitting in a homedir called fedora?
*** Bug 653979 has been marked as a duplicate of this bug. ***
(In reply to comment #1) User fedora is an ordinary member of group "users". $HOME/lib64 contains 64-bit versions of certain numerical shared libraries built and used locally by said user on this x86-64 system. The .login file read in by /bin/csh sets the dynamical link path to LD_LIBRARY_PATH=/home/fedora/lib64:/home/fedora/lib Attributes of $HOME/lib64 as reported by 'ls -Z' read drwxr-xr-x. fedora users unconfined_u:object_r:user_home_t:s0 . Today, I had installed the latest F14 updates, namely Nov 16 11:57:31 Updated: sane-backends-1.0.21-4.fc14.x86_64 Nov 16 11:57:38 Updated: sane-backends-libs-1.0.21-4.fc14.x86_64 Nov 16 11:57:39 Updated: sane-backends-libs-gphoto2-1.0.21-4.fc14.x86_64 Nov 16 11:57:47 Updated: gnome-desktop-2.32.0-2.fc14.x86_64 Nov 16 11:57:52 Updated: seed-2.31.91-2.fc14.x86_64 Nov 16 11:57:59 Updated: mousetweaks-2.32.0-1.fc14.x86_64 Nov 16 11:58:00 Updated: gnome-desktop-devel-2.32.0-2.fc14.x86_64 . I haven't observed the reported alert earlier than today.
Can you setup the correct file context then. # semanage fcontext -a -e /lib64 /home/fedora/lib64 # semanage fcontext -a -e /lib /home/fedora/lib restorecon -R -v /home/fedora Which will at least get it to a correct label.