Here's what it shows in the /var/log/audit.log

type=AVC msg=audit(1427924537.536:1669): avc:  denied  { write } for  pid=2397 comm="httpd" name="sqlite.db" dev="vda1" ino=403425494 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file
type=AVC msg=audit(1427924538.825:1670): avc:  denied  { write } for  pid=2397 comm="httpd" name="sqlite.db" dev="vda1" ino=403425494 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file
type=AVC msg=audit(1427924549.478:1671): avc:  denied  { write } for  pid=2396 comm="httpd" name="sqlite.db" dev="vda1" ino=403425494 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:httpd_sys_content_t:s0 tclass=file

To fix it I had to run the two following commands recommended by sealert

semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/roundcubemail/sqlite.db'

restorecon -v '/var/lib/roundcubemail/sqlite.db'

randomuser in IRC suggested the following probably would have worked:

restorecon -R /var/lib/roundcubemail/

Having already fixed it the way I did, I can't verify that... and I'm not going to break it in some way to test it. :)

If that is true, that means that an update to the roundcubemail package isn't needed... and that a clean install where a fresh sqlite.db file is created will probably work without issue.  That is to say that our guess is that the SELinux policy changed and just refreshing the context of my pre-existing file might have fixed it.

Anyway...

It seems there are other files kept there as well:

type=AVC msg=audit(1427977409.112:3854626): avc:  denied  { unlink } for  pid=11532 comm="httpd" name="453f2473e97e0ad0f2e69d1736e920f4.octet-stream" dev="sda1" ino=268428 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
type=AVC msg=audit(1427977409.112:3854627): avc:  denied  { unlink } for  pid=11532 comm="httpd" name="c1fcbed2b440847f48f2ce7275e85944.png" dev="sda1" ino=268586 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=file

ls -lZa /var/lib/roundcubemail/
drwxrwxr-x. root   apache system_u:object_r:var_lib_t:s0   .
drwxr-xr-x. root   root   system_u:object_r:var_lib_t:s0   ..
-rw-------. apache apache system_u:object_r:var_lib_t:s0   12d7a93b29427fc530a3986a2ac9e5ea.jpeg
-rw-------. apache apache system_u:object_r:var_lib_t:s0   15269169bba300541a7fdc68a45825b6.png
....

restorecon resets to var_lib_t, so that doesn't work.  I think you want:

semanage fcontext -a -t httpd_sys_rw_content_t '/var/lib/roundcubemail(/.*)?'

restorecon -r /var/lib/roundcubemail

Could you attach the list SELinux denials which appear in enforcing mode? Could you re-run your scenario in permissive mode and collect the denials as well?

# ausearch -m avc -m user_avc -m selinux_err -i -ts today

I'm not getting any errors.  The ausearch recommended in comment 6 shows nothing and that is with selinux in enforcing mode.

So, to the best of my knowledge, it isn't broken anymore and there isn't any data to gather.

I'm not able to reproduce this very well.  I do note that when you attach a file to an email in roundcube mail it creates a file in /var/lib/roundcubemail with context httpd_var_lib_t.  Perhaps something is coming along later and relabelling some files back to var_lib_t?

It happens automatically.

# matchpathcon /var/lib/roundcubemail
/var/lib/roundcubemail	system_u:object_r:var_lib_t:s0
#

Following rule says: if a process running as httpd_t creates a file or a directory under /var/lib/roundcubemail directory then the new object gets httpd_var_lib_t label.

# sesearch -s httpd_t -t var_lib_t -T
Found 2 semantic te rules:
   type_transition httpd_t var_lib_t : file httpd_var_lib_t; 
   type_transition httpd_t var_lib_t : dir httpd_var_lib_t; 

#

Right, but I was wondering what had set the labels on the file back to var_lib_t?  Anything in an update?  My running restorecon -r /var at some point?  At that point then it seems that roundcubemail cannot delete the files.

Not sure how Scott's sqlite.db file ended up as httpd_sys_content_t.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2300.html