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

Samuel Denbigh Leslie samuel.denbigh.leslie at gmail.com
Sat Sep 19 04:14:56 MDT 2009



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:



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.



More information about the samba mailing list