Hide Forgot
SELinux is preventing /usr/libexec/kde4/kcmdatetimehelper from 'write' accesses on the file /usr/libexec/kde4/lnusertemp. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that kcmdatetimehelper should be allowed write access on the lnusertemp 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 kcmdatetimehelp /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 Target Context system_u:object_r:bin_t:s0 Target Objects /usr/libexec/kde4/lnusertemp [ file ] Source kcmdatetimehelp Source Path /usr/libexec/kde4/kcmdatetimehelper Port <Unknown> Host (removed) Source RPM Packages kdebase-workspace-4.6.1-6.fc15 Target RPM Packages kdelibs-4.6.1-5.fc15 Policy RPM selinux-policy-3.9.16-13.fc15 Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 2.6.38.2-9.fc15.i686.PAE #1 SMP Wed Mar 30 16:47:28 UTC 2011 i686 i686 Alert Count 2 First Seen الخميس 19 أيار 2011 11:20:36 Last Seen الخميس 19 أيار 2011 11:21:27 Local ID 4d567077-cf54-4705-9139-ddfc882811e6 Raw Audit Messages type=AVC msg=audit(1305793287.408:136): avc: denied { write } for pid=7327 comm="kcmdatetimehelp" name="lnusertemp" dev=dm-1 ino=666409 scontext=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bin_t:s0 tclass=file type=SYSCALL msg=audit(1305793287.408:136): arch=i386 syscall=access success=no exit=EACCES a0=824b248 a1=2 a2=4a2a2430 a3=bfd32ef4 items=0 ppid=1 pid=7327 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=kcmdatetimehelp exe=/usr/libexec/kde4/kcmdatetimehelper subj=system_u:system_r:gnomeclock_t:s0-s0:c0.c1023 key=(null) Hash: kcmdatetimehelp,gnomeclock_t,bin_t,file,write audit2allow #============= gnomeclock_t ============== allow gnomeclock_t bin_t:file write; audit2allow -R #============= gnomeclock_t ============== allow gnomeclock_t bin_t:file write;
This looks a lot like https://bugzilla.redhat.com/show_bug.cgi?id=590883
So, the selinux policy workaround for this is no longer included?
Rex remind me what the workaround was?
See https://bugzilla.redhat.com/show_bug.cgi?id=590883#c28 and followups.
The existing fix is for xdm_t not gnomeclock_t. Are we going to be seeing a lot of new apps needing the dontaudit?
Well, almost ANY Qt/KDE app needs this dontaudit with Qt 4.7. gnomeclock_t now also covers the KDE clock KCM, which is how we end up with this AVC from gnomeclock_t. We could try backporting QFileInfo from Qt 4.8; as far as I can tell, the unnecessary access() calls should be fixed there. The central commit is http://qt.gitorious.org/qt/qt/commit/881b7547c2be0dc2b7e223175b8c43e4bda78991 (but there are both prerequisites and followup fixes). But what happened to the SELinux/kernel support for not misdetecting access() as an actual access, which was promised for F15 in the other bug?
To clarify the "almost any" part: This affects any app which uses QFileInfo::isExecutable on an executable, and kdelibs does that internally in several places.
PS: The bad news is that code reuse means the a lot of code is going to trigger the same bad access pattern even though it's only caused by one particular method inside Qt, the good news is that this also means it should be fixable in one single place. (That said, I'm not sure how safe backporting QFileInfo from 4.8 really is, nor have I verified that it really does fix the issue.)
When does the new version reach rawhide?
The dontaudit of access check is available in Rawhide Kernels now, but we are only doing it for xdm not every desktop app.
Qt 4.8 is currently in technical preview state, we haven't decided yet when to import it into Rawhide. (The main holdup is that right now, some KDE code is reported to have trouble compiling against it; I'm not sure of the details; normally, Qt is supposed to be both source- and binary-backwards-compatible.) We could try backporting QFileInfo from 4.8 to our 4.7 builds, also for F14 and F15. I'm not sure whether it's a good idea. (The changes are significant, but the 4.7 code is really broken, to be honest.) And why aren't we dontauditing all access checks in all contexts? An access check is not an actual access, I don't see why it needs to be treated as one.
Sounds ok to me, unless eparis can talk me out of it...
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.