The Berkeley DB library (libdb) is the current default for managing the KDB. The license of libdb changed in version 6, which is now using AGPLv3+. The terms of this license might not fit some use cases. Also the last update of libdb v5 (5.3.28) was released in 2020, and we don't expect any new update. As a consequence, we will switch to a different default KDB library and format for Fedora. The obvious alternative is LMDB since it has been supported by MIT Kerberos since 2018 (as "klmdb" DB plugin), and tested extensively since then. Reproducible: Always
Dist-git merge request: https://src.fedoraproject.org/rpms/krb5/pull-request/49
An existing Kerberos database can be migrated from the Berkeley DB to the LMDB format this way: systemctl stop krb5kdc kadmin now="$(date '+%Y%m%d%H%M%S')" kdb5_util dump "${XDG_RUNTIME_DIR}/krb5-${now}.kdb_dump" # Update /var/kerberos/krb5kdc/kdc.conf to use klmdb plugin kdb5_util load "${XDG_RUNTIME_DIR}/krb5-${now}.kdb_dump" restorecon -Rv /var/kerberos/krb5kdc systemctl start krb5kdc kadmin # Ensure principals were migrated properly rm -f "${XDG_RUNTIME_DIR}/krb5-${now}.kdb_dump" /var/kerberos/krb5kdc/{principal,principal.kadm5,principal.kadm5.lock,principal.ok} kpropd should be able to synchronize KDCs using a different KDB formats, because it uses the ASCII dump format, which is independent from the DB library.
The map operation seems to be required by the klmdb plugin: # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR | grep -E '(krb5kdc_t|kadmind_t)' type=AVC msg=audit(1708536086.456:512): avc: denied { map } for pid=1677 comm="krb5kdc" path="/var/kerberos/krb5kdc/principal.mdb-lock" dev="vda2" ino=262184 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=unconfined_u:object_r:krb5kdc_principal_t:s0 tclass=file permissive=1 This is the list of rules for krb5kdc_t processes on krb5kdc_principal_t files: # sesearch --allow --source krb5kdc_t --target krb5kdc_principal_t allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True allow domain file_type:file map; [ domain_can_mmap_files ]:True allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True allow krb5kdc_t file_type:filesystem getattr; allow krb5kdc_t krb5kdc_principal_t:file { append getattr ioctl lock open read write }; The last rule should probably be modified to add the "map" operation: allow krb5kdc_t krb5kdc_principal_t:file { append getattr ioctl lock map open read write }; I reported this issue to the selinux-policy component (bug 2265378).
After testing the selinux-policy update[1], there was another SELinux rule violation: # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR | grep -E '(krb5kdc_t|kadmind_t)' type=AVC msg=audit(1710409506.002:153): avc: denied { lock } for pid=868 comm="krb5kdc" path="/var/kerberos/krb5kdc/principal.mdb-lock" dev="vda2" ino=267778 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=unconfined_u:object_r:krb5kdc_principal_t:s0 tclass=file permissive=1 I also noticed that after deleting LMDB lock file (principal.mdb-lock and principal.lockout.mdb-lock) in /var/kerberos/krb5kdc, the krb5kdc daemon tries to recreate them when restarting: # ausearch -m AVC,USER_AVC,SELINUX_ERR,USER_SELINUX_ERR | grep -E '(krb5kdc_t|kadmind_t)' type=AVC msg=audit(1710409728.541:158): avc: denied { write } for pid=902 comm="krb5kdc" name="krb5kdc" dev="vda2" ino=267555 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1710409728.541:159): avc: denied { add_name } for pid=902 comm="krb5kdc" name="principal.mdb-lock" scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=dir permissive=1 type=AVC msg=audit(1710409728.541:160): avc: denied { create } for pid=902 comm="krb5kdc" name="principal.mdb-lock" scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file permissive=1 type=AVC msg=audit(1710409728.541:161): avc: denied { map } for pid=902 comm="krb5kdc" path="/var/kerberos/krb5kdc/principal.mdb-lock" dev="vda2" ino=267778 scontext=system_u:system_r:krb5kdc_t:s0 tcontext=system_u:object_r:krb5kdc_conf_t:s0 tclass=file permissive=1 The lock files are created with the krb5kdc_conf_t type instead of krb5kdc_principal_t (for both krb5kdc and kadmind): # ls -Zl /var/kerberos/krb5kdc/ total 104 -rw-------. 1 root root system_u:object_r:krb5kdc_conf_t:s0 22 Feb 18 19:00 kadm5.acl -rw-------. 1 root root system_u:object_r:krb5kdc_conf_t:s0 798 Feb 18 19:00 kdc.conf -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 45056 Mar 14 05:43 principal.lockout.mdb -rw-------. 1 root root system_u:object_r:krb5kdc_conf_t:s0 8192 Mar 14 05:48 principal.lockout.mdb-lock -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 45056 Mar 14 05:43 principal.mdb -rw-------. 1 root root system_u:object_r:krb5kdc_conf_t:s0 8192 Mar 14 05:48 principal.mdb-lock This issue does not occur for the kadmin daemon, because it has the "create" permission, contrary to krb5kdc: # sesearch --allow --source kadmind_t --target krb5kdc_principal_t allow domain file_type:blk_file map; [ domain_can_mmap_files ]:True allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True allow domain file_type:file map; [ domain_can_mmap_files ]:True allow domain file_type:lnk_file map; [ domain_can_mmap_files ]:True allow kadmind_t file_type:filesystem getattr; allow kadmind_t krb5kdc_principal_t:file { append create getattr ioctl link lock map open read rename setattr unlink watch watch_reads write }; Surprisingly the "add_name" permission is not part of the list for krb5kdc_principal_t files. [1] https://bodhi.fedoraproject.org/updates/FEDORA-2024-323decc1d9