samba - Feb 2017 - cifs-utils: regression in (mulituser?) mounting 'CIFS VFS: Send error in SessSetup = -126'

On Thu, 2017-02-09 at 14:45 -0600, Chad William Seys
wrote:
> Hi Jeff,
> Could you look at the following mailing list posting?
> 
> https://lists.samba.org/archive/samba/2017-February/206468.html
> 
> It looks like cifs.upcall has changed its behavior.  As described in 
> that post, I can mount with root / kerberos, but then cannot access with 
> another user who has credentials.
> 
> The logs indicate that cifs.upcall cannot find the kerberos ticket for 
> the non-root user.
> 
> This problem does not exist in cifs-utils 6.5 and does exist in 6.6 .
> 
> My best guess ATM is that the below commit caused the problem.
> 
> Thanks for your time!
> Chad.
> 
> commit 9be6e885c3bd63aa6ae9e6351e1b33a4b15d9183
> Author: Jeff Layton <jlayton at samba.org>
> Date:   Sun Aug 21 09:42:59 2016 -0400
> 
>      cifs.upcall: use krb5 routines to get default ccname
>      Currently we end up groveling around in /tmp, trying to guess what 
> the credcache will be. Instead, just get the default ccname for the 
> user, and then see if it has a valid tgt. If it doesn't then we try to 
> use the keytab to init the credcache before proceeding.

Thanks... let's see...

The logs have this in the non-working case:

     Feb  8 09:48:14 trog cifs.upcall: get_tgt_time: unable to get principal

That corresponds to this bit of code in cifs.upcall:

        if (krb5_cc_get_principal(context, ccache, &principal)) {
                syslog(LOG_DEBUG, "%s: unable to get principal",
__func__);
                goto err_cache;
        }

So we have a default credcache for the user for whom we are operating
as, but we can't get the default principal name from it. My guess is
that it's not finding the 

The big difference between 6.5 and 6.6 is that we changed to not trying
to scan /tmp for a credcache (which was always a bit sketchy). Instead,
we rely on the info in krb5.conf to point cifs.upcall to the correct
credcache. My guess is that that isn't working in your case for some
reason.

I'll see if I can cook up a patch to flesh out the debugging there a
bit. It'd be nice to see what it cifs.upcall thinks the current
credcache location is.

-- 
Jeff Layton <jlayton at samba.org>

Hi Jeff,
> So we have a default credcache for the user for whom we are operating
> as, but we can't get the default principal name from it. My guess is
> that it's not finding the
This mount is run by root UID=0 and seems to be find that credential 
cache without problem (earlier in the logs).  The problem seems to come 
in when it tries to find the cache for user with UID=1494 .

I'm wondering if the scan of /tmp was helpful for finding caches of 
non-same users.

(I'm a little surprised that there is any attempt to find credentials of 
the non-root user at mount time - what happens if the non-root user 
hasn't kinit-ed yet?  And yet that case worked in the past...)

Thanks for taking a look!
C.

On Fri, 2017-02-10 at 11:15 -0600, Chad William Seys
wrote:
> Hi Jeff,
> 
> > So we have a default credcache for the user for whom we are operating
> > as, but we can't get the default principal name from it. My guess
is
> > that it's not finding the
> 
> This mount is run by root UID=0 and seems to be find that credential 
> cache without problem (earlier in the logs).  The problem seems to come 
> in when it tries to find the cache for user with UID=1494 .
> 
> I'm wondering if the scan of /tmp was helpful for finding caches of 
> non-same users.
> 
> (I'm a little surprised that there is any attempt to find credentials
of
> the non-root user at mount time - what happens if the non-root user 
> hasn't kinit-ed yet?  And yet that case worked in the past...)
> 
I'm more interested in what the trailing info in your credcache name is.
In your log output for the working case, there are:

/tmp/krb5cc_0
/tmp/krb5cc_1494_sM11PG

So first one doesn't have that _XXXXXX trailing bit. Maybe cifs.upcall
is not guessing that piece of the filename correctly?

In any case, this patch should tell us more about what it thinks the
credcache location is when it's doing this. Do you have the ability to
apply this and test with the debugging turned up?


----------------------------------8<-------------------------------

cifs.upcall: extra debugging -- show the credcache location

Have the debugging show the full name of the default credcache that
was found.

Signed-off-by: Jeff Layton <jlayton at samba.org>
---
 cifs.upcall.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/cifs.upcall.c b/cifs.upcall.c
index 8f146c92b4a5..dd0843e358b1 100644
--- a/cifs.upcall.c
+++ b/cifs.upcall.c
@@ -159,6 +159,7 @@ get_default_cc(void)
 {
 	krb5_error_code ret;
 	krb5_ccache cc;
+	char *cachename;
 
 	ret = krb5_cc_default(context, &cc);
 	if (ret) {
@@ -166,6 +167,14 @@ get_default_cc(void)
 		return NULL;
 	}
 
+	ret = krb5_cc_get_full_name(context, cc, &cachename);
+	if (ret) {
+		syslog(LOG_DEBUG, "%s: krb5_cc_get_full_name failed: %d\n",
__func__, ret);
+	} else {
+		syslog(LOG_DEBUG, "%s: default ccache is %s\n", __func__,
cachename);
+		krb5_free_string(context, cachename);
+	}
+
 	if (!get_tgt_time(cc)) {
 		krb5_cc_close(context, cc);
 		cc = NULL;
-- 
2.9.3