[Samba] cifs.upcall not respecting krb5ccname env var?

[Samuel Denbigh Leslie]

Hello,

 

I've been doing some extensive troubleshooting with respect to some issues
mounting CIFS shares on a Windows box via Kerberos. We're using the command:

/sbin/mount.cifs //whatever/whatever /whatever -o sec=krb5i

 

This should mount the share using Kerberos & Packet-signing by using the
cached credentials of the user executing the command. With judicious use of
strace, it seems that cifs.upcall makes the assumption that the Kerberos
credentials will be present at /tmp/krb5cc_UID, however, this is not always
the case; the credentials may have a random element in the file name. Here's
an example output from the system:

/tmp/krb5cc_0  /tmp/krb5cc_10000_IKsPGl4129  /tmp/krb5cc_10003_SXDRDQ7677

 

As such, the command works fine under root, but will fail for users with
UIDs 10000 and 10003. I'm guessing the difference is in logon mechanism;
root is logged on locally while the 1000* UIDs are logging in over SSH.
Eliminating the random element would not be feasible as a single user may
have multiple Kerberos cached credentials.


The correct behaviour should be to read the value of the KRB5CCNAME
variable, which if present, should point to the correct location of the
Kerberos cached credentials for that session, and if not, use the present
default of /tmp/krb5cc_UID. Example output:

KRB5CCNAME=FILE:/tmp/krb5cc_10000_IKsPGl4129

 

At no point in the strace logs of both successful and failed mounts for
mount.cifs or cifs.upcall is the getenv() syscall used, it would appear it
is making a (seriously incorrect) assumption and completely disregarding the
relevant environment variable.

 

I'm not a Linux expert, and may have this completely wrong, but can anyone
else shed some insight into this. Is this a bug?

 

Note that symlinking krb5cc_UID to the correct credentials will fix the
problems, but this is not a feasible solution long term.

 

-SDL