Fedora Account System
Red Hat Associate
Red Hat Customer
There is a difference of permissions between krb5kdc and kadmind daemons. I am not sure if this is justified, especially with the recent switch from Berkeley DB to LMDB, this is causing some issues. Permission of the kadmind daemon on the principal DB files: # 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 }; Permission of the krb5kdc daemon on the principal DB files (before changes from bug 2265378): # 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 }; After initializing the KDC database the following DB files are created: # kdb5_util create [...] # ls -lZ /var/kerberos/krb5kdc/principal* -rw-------. 1 root root unconfined_u:object_r:krb5kdc_conf_t:s0 45056 Mar 14 14:37 /var/kerberos/krb5kdc/principal.lockout.mdb -rw-------. 1 root root unconfined_u:object_r:krb5kdc_conf_t:s0 8192 Mar 14 14:37 /var/kerberos/krb5kdc/principal.lockout.mdb-lock -rw-------. 1 root root unconfined_u:object_r:krb5kdc_conf_t:s0 45056 Mar 14 14:37 /var/kerberos/krb5kdc/principal.mdb -rw-------. 1 root root unconfined_u:object_r:krb5kdc_conf_t:s0 8192 Mar 14 14:37 /var/kerberos/krb5kdc/principal.mdb-lock Then have invalid contexts. *.mdb files should have the krb5kdc_principal_t type, and *.mdb-lock should have the krb5kdc_lock_t type. restorecon does not completely fix the issue, because it assigns krb5kdc_principal_t to all of them: # restorecon -Rv /var/kerberos/krb5kdc/ Relabeled /var/kerberos/krb5kdc/principal.mdb-lock from unconfined_u:object_r:krb5kdc_conf_t:s0 to unconfined_u:object_r:krb5kdc_principal_t:s0 Relabeled /var/kerberos/krb5kdc/principal.mdb from unconfined_u:object_r:krb5kdc_conf_t:s0 to unconfined_u:object_r:krb5kdc_principal_t:s0 Relabeled /var/kerberos/krb5kdc/principal.lockout.mdb-lock from unconfined_u:object_r:krb5kdc_conf_t:s0 to unconfined_u:object_r:krb5kdc_principal_t:s0 Relabeled /var/kerberos/krb5kdc/principal.lockout.mdb from unconfined_u:object_r:krb5kdc_conf_t:s0 to unconfined_u:object_r:krb5kdc_principal_t:s0 # ls -lZ /var/kerberos/krb5kdc/principal* -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 45056 Mar 14 14:37 /var/kerberos/krb5kdc/principal.lockout.mdb -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 8192 Mar 14 14:37 /var/kerberos/krb5kdc/principal.lockout.mdb-lock -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 45056 Mar 14 14:37 /var/kerberos/krb5kdc/principal.mdb -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 8192 Mar 14 14:37 /var/kerberos/krb5kdc/principal.mdb-lock As a comparison, kdb5_util creates the files with the right context directory when using Berkeley DB: # kdb5_util create [...] # ls -lZ /var/kerberos/krb5kdc/principal* -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 8192 Mar 14 14:23 /var/kerberos/krb5kdc/principal -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 8192 Mar 14 14:23 /var/kerberos/krb5kdc/principal.kadm5 -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 0 Mar 14 14:23 /var/kerberos/krb5kdc/principal.kadm5.lock -rw-------. 1 root root unconfined_u:object_r:krb5kdc_lock_t:s0 0 Mar 14 14:23 /var/kerberos/krb5kdc/principal.ok Also the *.mdb-lock may be deleted later, and recreated by kadmind or krb5kdc daemons instead of kdb5_util. kadmind creates files with krb5kdc_conf_t instead of krb5kdc_lock_t too: # ls -Zl /var/kerberos/krb5kdc/principal* -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 45056 Mar 14 05:43 /var/kerberos/krb5kdc/principal.lockout.mdb -rw-------. 1 root root system_u:object_r:krb5kdc_conf_t:s0 8192 Mar 14 05:48 /var/kerberos/krb5kdc/principal.lockout.mdb-lock -rw-------. 1 root root unconfined_u:object_r:krb5kdc_principal_t:s0 45056 Mar 14 05:43 /var/kerberos/krb5kdc/principal.mdb -rw-------. 1 root root system_u:object_r:krb5kdc_conf_t:s0 8192 Mar 14 05:48 /var/kerberos/krb5kdc/principal.mdb-lock On the other hand, krb5kdc is unable to create *.mdb-lock at all, because it does not have the required permissions: # 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 So the required changes should be: 1. Allow krb5kdc_t processes to create krb5kdc_lock_t files. 2. Make sure kadmind_t and krb5kdc_t processes create /var/kerberos/krb5kdc/{principal.mdb-lock,principal.lockout.mdb-lock} files with type krb5kdc_lock_t. 3. Make sure the kdb5_util command creates /var/kerberos/krb5kdc/{principal.mdb,principal.lockout.mdb} files with type krb5kdc_principal_t, and /var/kerberos/krb5kdc/{principal.mdb-lock,principal.lockout.mdb-lock} files with type krb5kdc_lock_t. Reproducible: Always
This bug appears to have been reported against 'rawhide' during the Fedora Linux 42 development cycle. Changing version to 42.
This message is a reminder that Fedora Linux 42 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13. 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 'version' of '42'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 42 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 Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27. Fedora Linux 42 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.