Description of problem: I updated an existing machine from F31 to F32 and found that saslauthd would no longer function to check passwords against the kerberos database: Sep 12 01:17:18 mx2.math.uh.edu saslauthd[13046]: auth_krb5: krb5_rd_req(): Permission denied (filename: /var/tmp/krb5_0.rcache2) (13) Sep 12 01:17:18 mx2.math.uh.edu saslauthd[13046]: auth_krb5: k5support_verify_tgt Sep 12 01:17:18 mx2.math.uh.edu saslauthd[13046]: : auth failure: [user=tibbs] [service=imap] [realm=] [mech=kerberos5] [reason=saslauthd internal error] ausearch shows nothing at all but I had a hunch to disable selinux anyway and indeed everything starts working after "setenforce 0". I realize this might be due to some dontaudit rule, so after semodule -DB I found: type=AVC msg=audit(1599891699.328:493): avc: denied { write } for pid=13049 comm="saslauthd" name="krb5_0.rcache2" dev="dm-1" ino=3985 scontext=system_u:system_r:saslauthd_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1 To be honest I don't know what that /dev/tmp/krb5_0.rcache2 file is. It doesn't appear to be present in F31 (which has cyrus-sasl-2.1.27-3.fc31.x86_64) but the packaging doesn't seem to be that different so I suspect the real difference is somewhere in the underlying krb5 library, which went from krb5-libs-1.17-46.fc31.x86_64 to krb5-libs-1.18.2-20.fc32.x86_64. -rw-------. 1 root root system_u:object_r:user_tmp_t:s0 15680 Sep 12 02:02 /var/tmp/krb5_0.rcache2 A naive audit2allow run allows me to run with selinux enabled but something tells me that the real solution is more involved. Version-Release number of selected component (if applicable): cyrus-sasl-lib-2.1.27-4.fc32.x86_64 cyrus-sasl-plain-2.1.27-4.fc32.x86_64 cyrus-sasl-2.1.27-4.fc32.x86_64 cyrus-sasl-gssapi-2.1.27-4.fc32.x86_64 selinux-policy-3.14.5-43.fc32.noarch selinux-policy-targeted-3.14.5-43.fc32.noarch How reproducible: 100% Steps to Reproduce: 1. Setup saslauthd with the kerberos5 mech authing to an existing krb5 server. 2. Run testsaslauthd -u XXX -p YYY (with valid credentials, of course) Actual results: 0: NO "authentication failed" Plus the logged failure indicated above, and (with dontaudit rules disabled) the AVC listed above. Expected results: 0: OK "Success." with nothing logged and no AVC.
Hi, The filename for reply cache really changed in the new kerberos library, but we added a bunch rules reflecting that since than. Do you know which service created the file in your case?
In which context do you use "service"? I believe that no running daemon besides saslauthd is involved, but the SASL service used by testsaslauthd seems to be "imap" and the actual SASL service involved in the denials that I tested is "smtp". But the machine also runs an LDAP server, and looking at the currently existing caches I see one called "krb5_55.rcache2". The UID of the "ldap" user is 55. -rw-------. 1 root root system_u:object_r:user_tmp_t:s0 16032 Sep 14 10:37 /var/tmp/krb5_0.rcache2 -rw-------. 1 ldap ldap system_u:object_r:slapd_tmp_t:s0 10928 Sep 13 18:51 /var/tmp/krb5_55.rcache2 I checked an identical machine that is still running F31 and see the following two files: -rw-------. 1 root root system_u:object_r:krb5_host_rcache_t:s0 219 Sep 14 10:45 host_0 -rw-------. 1 ldap ldap system_u:object_r:krb5_host_rcache_t:s0 681 Sep 14 00:32 ldap_55 I'm pretty sure those show what the corresponding names used to be.
PR: https://github.com/fedora-selinux/selinux-policy/pull/636
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. 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 32 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 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 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.
PR merged: https://github.com/fedora-selinux/selinux-policy/pull/636
FEDORA-2021-3a592334ef has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-3a592334ef
FEDORA-2021-3a592334ef has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-3a592334ef` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-3a592334ef See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-3a592334ef has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.