krb5: improve reporting failure on reading keytab

[257]

also, s/has not entries/has no entries/ when keytab_file has actually
no entries.

Signed-off-by: Paymon MARANDI paymon@encs.concordia.ca

[gemini-code-assist]

Code Review

The pull request introduces a valuable check for keytab file readability, which enhances error reporting and robustness. This is a good improvement for handling cases where the keytab file exists but cannot be accessed by the process. However, a typo was introduced in the debug message for this new check.

[alexey-tikhonov]

Perhaps tests need update:

[  FAILED  ] tests: 2 test(s), listed below:
[  FAILED  ] test_copy_keytab
[  FAILED  ] test_copy_keytab_order

But what is your use case? Typically 'krb5_child' has cap_dac_read_search to read keytab.

[257]

Perhaps tests need update:

[  FAILED  ] tests: 2 test(s), listed below:
[  FAILED  ] test_copy_keytab
[  FAILED  ] test_copy_keytab_order

will have a look

But what is your use case? Typically 'krb5_child' has cap_dac_read_search to read keytab.

cap_dac_read_search seems to require at least ownership? i can't really tell from the man page so i'm not sure why it didn't apply here.

in our case, our logs would show:
(2026-03-17 9:28:46): [ldap_child[7149]] [copy_keytab_into_memory] (0x0020): [RID#3] keytab [FILE:/etc/krb5.keytab] has not entries.

actual problem was that the build pipeline (homegrown, based on mkosi) included /etc/krb5.keytab in the image that had wrong owner/permission:
-rw------- 1 root root /etc/krb5.keytab

obviously logs didn't help in our troubleshooting hence this patch. (although it pointed to the right direction)

chown'ing that file to: -rw-rw---- 1 root sssd 213 Mar 16 17:26 /etc/krb5.keytab fixed the problem for us.

a side note, I have two questions:

• we would like to move to systemd-creds for passing the keytab file to sssd and would like to know if community has already tried or seen an "implementaiton" of that?
  -cap_dac_read_search didn't help in our case, man page says:

CAP_DAC_READ_SEARCH
              •  Bypass file read permission checks and directory read
                 and execute permission checks;
              •  invoke [open_by_handle_at(2)](https://man7.org/linux/manpages/man2/open_by_handle_at.2.html);
              •  use the [linkat(2)](https://man7.org/linux/man-pages/man2/linkat.2.html) AT_EMPTY_PATH flag to create a link to a file referred to by a file descriptor.

does that mean that the ownership already has to be set for the user?

[alexey-tikhonov]

actual problem was that the build pipeline (homegrown, based on mkosi) included /etc/krb5.keytab in the image that had wrong owner/permission: -rw------- 1 root root /etc/krb5.keytab

That's actually pretty typical ownership.

Can you check output of getcap /usr/libexec/sssd/* in your custom image?
Normally it should be:

/usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p
/usr/libexec/sssd/ldap_child cap_dac_read_search=p
/usr/libexec/sssd/sssd_pam cap_dac_read_search=p

I suspect file capabilities are lost in your image.

obviously logs didn't help in our troubleshooting hence this patch.

Thank you.

chown'ing that file to: -rw-rw---- 1 root sssd 213 Mar 16 17:26 /etc/krb5.keytab fixed the problem for us.

This also works, in this case SSSD binaries in your image don't need 'cap_dac_read_search'.

* we would like to move to `systemd-creds` for passing the keytab file to sssd and would like to know if community has already tried or seen an "implementaiton" of that?

That's an interesting option, we didn't explore it yet.

  -`cap_dac_read_search` didn't help in our case, man page says:

...

does that mean that the ownership already has to be set for the user?

No, it's not required. cap_dac_read_search allows to fully bypass DAC controls

[257]

Can you check output of getcap /usr/libexec/sssd/* in your custom image? Normally it should be:

/usr/libexec/sssd/krb5_child cap_dac_read_search,cap_setgid,cap_setuid=p
/usr/libexec/sssd/ldap_child cap_dac_read_search=p
/usr/libexec/sssd/sssd_pam cap_dac_read_search=p

comes up empty! in fact i ended up chown'in /usr/libexec/sssd/sssd_pam to get it to run and was going to submit a patch for that too!

then i saw this and this

build script (gentoo's portage) indeed passes --with-sssd-user=sssd

I suspect file capabilities are lost in your image.

they're indeed lost, great call; thanks.

i cooked up something for the distro, waiting for their feedback.