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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
