(In reply to comment #12)
> Could this be a leak in systemd?
Only if for PAM got loaded into apache in some way and went through a session registration.
Nicolas, did you use any special Apache configuration?

(In reply to comment #15)
> Does squirrelmail do authorization using the pam stack?
it's supposed to talk to an imap server, that does its own authorisation
But anyway there is no need to focus on apache since most of the dupes are for other system apps

I got this same error, but in that case it was systemd trying to rotate log files. SElinux stopped it from being able to rotate those logs. Isn't systemd supposed to have fifo access to files and to be able to rotate logs? In my case, there was no yum transaction going on. I was just reading a book on the Internet over at Amazon.com. This error was immediately followed by three more involving /bin/bash. Again, I was doing nothing but reading an e-Text. A quick check using system monitor to view all processes showed that neither yum nor PackageKit were running at the time of the errors.

Crap! I wish you had asked me that yesterday. :-)
Unfortunately, I deleted everything from the SELinux troubleshooter after updating selinux-policy early this morning. (I was watching the build on Koji and updated as soon as building was complete). If I see this again, I'll send it up.
However, the SELinux Troubleshooter itself referred me here initially.

The same happens to me since upgrading to systemd 210 whenever cronjobs run.
In my case, this happens during cron.daily for logrotate, bash (man-db, I guess) and updatedb.
SELinux is preventing /usr/bin/updatedb from write access on the fifo_file /run/systemd/sessions/2.ref (deleted).
***** Plugin leaks (86.2 confidence) suggests *****************************
If you want to ignore updatedb trying to write access the 2.ref (deleted) fifo_file, because you believe it should not need this access.
Then you should report this as a bug.
You can generate a local policy module to dontaudit this access.
Do
# grep /usr/bin/updatedb /var/log/audit/audit.log | audit2allow -D -M mypol
# semodule -i mypol.pp
***** Plugin catchall (14.7 confidence) suggests **************************
If you believe that updatedb should be allowed write access on the 2.ref (deleted) fifo_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 updatedb /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

(In reply to Daniel Walsh from comment #29)
> Just checked in a dontaudit for this access.
> 9d4e76afdae04cb79e8b0e2222051b60e7d6b021 Since it does not seem to be being
> fixed.
I think this should be fixed by http://cgit.freedesktop.org/systemd/systemd/commit/?id=85c08dc013. It was v212-348-g85c08dc013 upstream, and has landed in F21/F22/F23 a while ago.
Can you revert the dontaudit rule?

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.
(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)
More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23