Description of problem: Just popped up on a reboot (system had hung prior to the reboot). SELinux is preventing /usr/sbin/chronyd from using the 'getsession' accesses on a process. ***** Plugin catchall (100. confidence) suggests *************************** If you believe that chronyd should be allowed getsession access on processes labeled audisp_t 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 chronyd /var/log/audit/audit.log | audit2allow -M mypol # semodule -i mypol.pp Additional Information: Source Context system_u:system_r:chronyd_t:s0 Target Context system_u:system_r:audisp_t:s0 Target Objects [ process ] Source chronyd Source Path /usr/sbin/chronyd Port <Unknown> Host (removed) Source RPM Packages chrony-1.27-3.fc19.x86_64 Target RPM Packages Policy RPM selinux-policy-3.12.1-48.fc19.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64 x86_64 Alert Count 1 First Seen 2013-06-13 15:38:13 PDT Last Seen 2013-06-13 15:38:13 PDT Local ID a80fc3bb-2a6e-4870-823f-c928664eb656 Raw Audit Messages type=AVC msg=audit(1371163093.923:25): avc: denied { getsession } for pid=597 comm="chronyd" scontext=system_u:system_r:chronyd_t:s0 tcontext=system_u:system_r:audisp_t:s0 tclass=process type=SYSCALL msg=audit(1371163093.923:25): arch=x86_64 syscall=getsid success=no exit=EACCES a0=23c a1=1 a2=7fd12a5cb7d8 a3=23c items=0 ppid=1 pid=597 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=chronyd exe=/usr/sbin/chronyd subj=system_u:system_r:chronyd_t:s0 key=(null) Hash: chronyd,chronyd_t,audisp_t,process,getsession Additional info: reporter: libreport-2.1.4 hashmarkername: setroubleshoot kernel: 3.9.5-301.fc19.x86_64 type: libreport
Does chrony have anything to do with audit?
Chrony doesn't have anything to do with audit. On start, when /var/run/chronyd.pid exists, chronyd tries getsid(pid) to see if there is another chronyd running. How could this happen on boot, when /var/run is empty, I'm not sure.
It seems recent systemd versions remove pid file specified in the service file when the service is stopped. chronyd is normally unable to remove its pid file when stopping due to dropped root permissions, but we can now let systemd to do it and prevent the problem with another process reusing the same pid and chronyd trying to run getsid() on it. This is in chrony-1.29-3.fc21.