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

[Jeff Layton]

On Sat, 19 Sep 2009 20:14:56 +1000
"Samuel Denbigh Leslie" <samuel.denbigh.leslie at gmail.com> wrote:

> 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
> 

(side-note: The random element is usually placed there by pam_krb5)

>  
> 
> 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.
> 
> 

No, you're correct. cifs.upcall shipping today with most distros doesn't
handle this correctly.

The latest version of cifs.upcall in samba's git tree should have a fix
for this. We can't actually use the value of $KRB5CCNAME since we
cannot guarantee that it'll be set to the correct value if the
reconnect is handled in the context of a different user.

The scheme is to search /tmp for the best possible credcache and to use
that instead. You may want to try pulling down the latest samba git
tree and building the latest cifs.upcall there (the one in the master
branch).

-- 
Jeff Layton <jlayton at redhat.com>