samba - Sep 2009 - cifs.upcall not respecting krb5ccname env var?

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

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>