Additional info: libreport version: 2.0.13 kernel: 3.6.0-0.rc2.git2.1.fc18.x86_64 description: :SELinux is preventing /usr/libexec/dovecot/auth from 'block_suspend' accesses on the capability2 . : :***** Plugin catchall (100. confidence) suggests *************************** : :If vous pensez que auth devrait être autorisé à accéder block_suspend sur capability2 par défaut. :Then vous devriez rapporter ceci en tant qu'anomalie. :Vous pouvez générer un module de stratégie local pour autoriser cet accès. :Do :autoriser cet accès pour le moment en exécutant : :# grep auth /var/log/audit/audit.log | audit2allow -M mypol :# semodule -i mypol.pp : :Additional Information: :Source Context system_u:system_r:dovecot_auth_t:s0 :Target Context system_u:system_r:dovecot_auth_t:s0 :Target Objects [ capability2 ] :Source auth :Source Path /usr/libexec/dovecot/auth :Port <Inconnu> :Host (removed) :Source RPM Packages dovecot-2.1.9-2.fc19.x86_64 :Target RPM Packages :Policy RPM selinux-policy-3.11.1-18.fc18.noarch :Selinux Enabled True :Policy Type targeted :Enforcing Mode Enforcing :Host Name (removed) :Platform Linux (removed) 3.6.0-0.rc2.git2.1.fc18.x86_64 #1 : SMP Wed Aug 22 11:54:04 UTC 2012 x86_64 x86_64 :Alert Count 2 :First Seen 2012-09-15 11:37:10 CEST :Last Seen 2012-09-15 11:37:10 CEST :Local ID 2c2e3715-53bd-47ce-afeb-84b29521cd19 : :Raw Audit Messages :type=AVC msg=audit(1347701830.295:150): avc: denied { block_suspend } for pid=2694 comm="auth" capability=36 scontext=system_u:system_r:dovecot_auth_t:s0 tcontext=system_u:system_r:dovecot_auth_t:s0 tclass=capability2 : : :type=SYSCALL msg=audit(1347701830.295:150): arch=x86_64 syscall=epoll_ctl success=yes exit=0 a0=a a1=2 a2=8 a3=7fffb8c5b160 items=0 ppid=743 pid=2694 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=auth exe=/usr/libexec/dovecot/auth subj=system_u:system_r:dovecot_auth_t:s0 key=(null) : :Hash: auth,dovecot_auth_t,dovecot_auth_t,capability2,block_suspend : :audit2allow : :#============= dovecot_auth_t ============== :allow dovecot_auth_t self:capability2 block_suspend; : :audit2allow -R : :#============= dovecot_auth_t ============== :allow dovecot_auth_t self:capability2 block_suspend; : :No idea what it means
Created attachment 613225 [details] File: type
Created attachment 613226 [details] File: hashmarkername
Eric, Second call that I have seen to epoll_ctl that generates a block_suspend but the call is successful.success=yes even though the machine in enforcing mode. Could this be a bug in the kernel? Or is the syscall just taking a different path if this is blocked. Also in #857629
Code in question: /* Check if EPOLLWAKEUP is allowed */ if ((epds.events & EPOLLWAKEUP) && !capable(CAP_BLOCK_SUSPEND)) epds.events &= ~EPOLLWAKEUP; If an application is failing this capability check, it is because it explictly ask for EPOLLWAKEUP. The syscall won't fail, but we probably should check with each application you see these for an determine if they actually need it. This is not a particularly dangerous thing, from what I can see. Just means the app can use some more battery....
Ok dovecot maintainer, do you actually think dovecot needs to be able to block suspend?
(In reply to comment #5) > Ok dovecot maintainer, do you actually think dovecot needs to be able to > block suspend? The answer is I don't know. I don't know when it is good idea to use it nor when it's a bad idea to use it. I searched for some documentation, but found nothing. Could you point me somewhere where I could get more information? Google failed me this time.
I think the idea of this access is to stop the machine from suspending while the tool is executing. /* Allow preventing system suspends */ #define CAP_BLOCK_SUSPEND 36 It used to be called epollwakeup. When an epoll_event, that has the EPOLLWAKEUP flag set, is ready, a wakeup_source will be active to prevent suspend. This can be used to handle wakeup events from a driver that support poll, e.g. input, if that driver wakes up the waitqueue passed to epoll before allowing suspend.
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 bug has been marked as a duplicate of bug 1136575 ***