Fix: Fixes mount problems with Kerberos after cifs-utils update

[ks98]

Fix: Resolve mount issues with Kerberos (sec=krb5) after cifs-utils update

Problem Description

Since a recent update to the cifs-utils package, which includes the security fix for CVE-2025-2312, CIFS mounts using Kerberos authentication (sec=krb5) are failing on our Linux clients.

This manifests as the following error messages in the kernel log (dmesg):

CIFS: VFS: cifs_mount failed w/return code = -123
CIFS: Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE
CIFS: Send error in SessSetup = -123

The mount command, which is executed in the background upon login, fails.

Root Cause Analysis

The issue is caused by an unfortunate interaction between the default behavior of Kerberos and a deliberate change in cifs-utils:

1. Kerberos: By default, newer versions of Kerberos create a credential cache with a random suffix (e.g., /tmp/krb5cc_215604408_aBcXyZ) to avoid collisions between multiple concurrent sessions. This behavior has existed for some time but was previously tolerated by cifs-utils.

2. cifs-utils (post-CVE-2025-2312): To address a security vulnerability, the cifs.upcall helper program was hardened. The previous "smart" behavior of scanning the /tmp directory for matching cache files (krb5cc_<UID>*) has been removed. cifs.upcall now strictly and exclusively looks for the fixed path without a suffix (e.g., FILE:/tmp/krb5cc_215604408).

Conclusion: Kerberos creates a cache with a suffix, but cifs.upcall looks for one without. As a result, the cache is not found, and authentication fails.

The Solution

This PR fixes the issue by adjusting the Kerberos configuration (/etc/krb5.conf). This instructs Kerberos to revert to using a fixed cache path without a suffix, which matches the expectations of the hardened cifs.upcall.

The following configuration is added to the [libdefaults] section of /etc/krb5.conf:

[libdefaults]
    default_ccache_name = FILE:/tmp/krb5cc_%{uid}

Considerations and Rationale

This solution deliberately restores an older Kerberos behavior. This is a pragmatic compromise, as it is currently the only reliable method to ensure compatibility with the security-hardened cifs-utils package.

The disadvantage of this approach (the risk of cache collisions with several simultaneous sessions of the same user) can be neglected for the typical use case of a desktop client in my opinion. In this context, restoring the functionality of Kerberos mounts has higher priority.

[dorianim]

Thank you for the detailed description.
I don't have any time to properly look into this until presumably mid-August.
@kiarn what do you think?