Quantcast

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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
Hello,
   On Debian 9 (stretch prerelease) I am able to mount with the following
command with root using the following command:
mount -t cifs //smb.physics.wisc.edu/smb /smb
-osec=krb5,multiuser,username=[hidden email] --verbose

   root can also access files as expected
   However, when cifs-utils 6.6-5 is installed, a different user cannot
access as expected:
ls /smb
ls: cannot access '/smb': Permission denied

   But when cifs-utils 6.4-1 is installed (from jessie) the different
user can access as expect.  AFAIK there are no other differences besides
the cifs-utils version.

   The first difference in syslog is "kernel: [223018.425633] CIFS VFS:
Send error in SessSetup = -126".  I'll paste the working
and non-working logs below.  The "different user" mentioned above has
UID 1494 which appears in the logs.

Thanks for your time!
C.

WORKING:
cifs-utils v 6.4-1
Feb  8 09:51:46 trog cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=
0x0;creduid=0x0;user=[hidden email];pid=0x6bd0
Feb  8 09:51:46 trog cifs.upcall: ver=2
Feb  8 09:51:46 trog cifs.upcall: host=smb.physics.wisc.edu
Feb  8 09:51:46 trog cifs.upcall: ip=128.104.160.17
Feb  8 09:51:46 trog cifs.upcall: sec=1
Feb  8 09:51:46 trog cifs.upcall: uid=0
Feb  8 09:51:46 trog cifs.upcall: creduid=0
Feb  8 09:51:46 trog cifs.upcall: user=[hidden email]
Feb  8 09:51:46 trog cifs.upcall: pid=27600
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: scandir error on
directory '/run/user/0': No such file or directory
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_0 is
valid ccache
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: considering
/tmp/krb5cc_1494_sM11PG
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: /tmp/krb5cc_1494_sM11PG
is owned by 1494, not 0
Feb  8 09:51:46 trog cifs.upcall: handle_krb5_mech: getting service
ticket for smb.physics.wisc.edu
Feb  8 09:51:46 trog cifs.upcall: handle_krb5_mech: obtained service ticket
Feb  8 09:51:46 trog cifs.upcall: Exit status 0
Feb  8 09:51:46 trog cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=0x0;creduid=0x0;user=[hidden email];pid=0x6bd0
Feb  8 09:51:46 trog cifs.upcall: ver=2
Feb  8 09:51:46 trog cifs.upcall: host=smb.physics.wisc.edu
Feb  8 09:51:46 trog cifs.upcall: ip=128.104.160.17
Feb  8 09:51:46 trog cifs.upcall: sec=1
Feb  8 09:51:46 trog cifs.upcall: uid=0
Feb  8 09:51:46 trog cifs.upcall: creduid=0
Feb  8 09:51:46 trog cifs.upcall: user=[hidden email]
Feb  8 09:51:46 trog cifs.upcall: pid=27600
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: scandir error on
directory '/run/user/0': No such file or directory
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: FILE:/tmp/krb5cc_0 is
valid ccache
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: considering
/tmp/krb5cc_1494_sM11PG
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: /tmp/krb5cc_1494_sM11PG
is owned by 1494, not 0
Feb  8 09:51:46 trog cifs.upcall: handle_krb5_mech: getting service
ticket for smb.physics.wisc.edu
Feb  8 09:51:46 trog cifs.upcall: handle_krb5_mech: obtained service ticket
Feb  8 09:51:46 trog cifs.upcall: Exit status 0
Feb  8 09:51:46 trog cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=0x5d6;creduid=0x5d6;pid=0x6725
Feb  8 09:51:46 trog cifs.upcall: ver=2
Feb  8 09:51:46 trog cifs.upcall: host=smb.physics.wisc.edu
Feb  8 09:51:46 trog cifs.upcall: ip=128.104.160.17
Feb  8 09:51:46 trog cifs.upcall: sec=1
Feb  8 09:51:46 trog cifs.upcall: uid=1494
Feb  8 09:51:46 trog cifs.upcall: creduid=1494
Feb  8 09:51:46 trog cifs.upcall: pid=26405
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: considering /tmp/krb5cc_0
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: /tmp/krb5cc_0 is owned
by 0, not 1494
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc: considering
/tmp/krb5cc_1494_sM11PG
Feb  8 09:51:46 trog cifs.upcall: find_krb5_cc:
FILE:/tmp/krb5cc_1494_sM11PG is valid ccache
Feb  8 09:51:46 trog cifs.upcall: handle_krb5_mech: getting service
ticket for smb.physics.wisc.edu
Feb  8 09:51:46 trog cifs.upcall: handle_krb5_mech: obtained service ticket
Feb  8 09:51:46 trog cifs.upcall: Exit status 0


NON-WORKING
cifs-utils v 6.6-5
eb  8 09:48:14 trog cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=0x0;creduid=0x0;user=[hidden email];pid=0x67d2
Feb  8 09:48:14 trog cifs.upcall: ver=2
Feb  8 09:48:14 trog cifs.upcall: host=smb.physics.wisc.edu
Feb  8 09:48:14 trog cifs.upcall: ip=128.104.160.17
Feb  8 09:48:14 trog cifs.upcall: sec=1
Feb  8 09:48:14 trog cifs.upcall: uid=0
Feb  8 09:48:14 trog cifs.upcall: creduid=0
Feb  8 09:48:14 trog cifs.upcall: user=[hidden email]
Feb  8 09:48:14 trog cifs.upcall: pid=26578
Feb  8 09:48:14 trog cifs.upcall: get_tgt_time: unable to get principal
Feb  8 09:48:14 trog cifs.upcall: handle_krb5_mech: getting service
ticket for smb.physics.wisc.edu
Feb  8 09:48:14 trog cifs.upcall: handle_krb5_mech: obtained service ticket
Feb  8 09:48:14 trog cifs.upcall: Exit status 0
Feb  8 09:48:14 trog cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=0x0;creduid=0x0;user=[hidden email];pid=0x67d2
Feb  8 09:48:14 trog cifs.upcall: ver=2
Feb  8 09:48:14 trog cifs.upcall: host=smb.physics.wisc.edu
Feb  8 09:48:14 trog cifs.upcall: ip=128.104.160.17
Feb  8 09:48:14 trog cifs.upcall: sec=1
Feb  8 09:48:14 trog cifs.upcall: uid=0
Feb  8 09:48:14 trog cifs.upcall: creduid=0
Feb  8 09:48:14 trog cifs.upcall: user=[hidden email]
Feb  8 09:48:14 trog cifs.upcall: pid=26578
Feb  8 09:48:14 trog cifs.upcall: handle_krb5_mech: getting service
ticket for smb.physics.wisc.edu
Feb  8 09:48:14 trog cifs.upcall: handle_krb5_mech: obtained service ticket
Feb  8 09:48:14 trog cifs.upcall: Exit status 0
Feb  8 09:48:14 trog cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=0x5d6;creduid=0x5d6;pid=0x6725
Feb  8 09:48:14 trog cifs.upcall: ver=2
Feb  8 09:48:14 trog cifs.upcall: host=smb.physics.wisc.edu
Feb  8 09:48:14 trog kernel: [223018.425633] CIFS VFS: Send error in
SessSetup = -126
Feb  8 09:48:14 trog cifs.upcall: ip=128.104.160.17
Feb  8 09:48:14 trog cifs.upcall: sec=1
Feb  8 09:48:14 trog cifs.upcall: uid=1494
Feb  8 09:48:14 trog cifs.upcall: creduid=1494
Feb  8 09:48:14 trog cifs.upcall: pid=26405
Feb  8 09:48:14 trog cifs.upcall: get_tgt_time: unable to get principal
Feb  8 09:48:14 trog cifs.upcall: Exit status 1

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
Chad William Seys via samba <[hidden email]> writes:
>    But when cifs-utils 6.4-1 is installed (from jessie) the different
> user can access as expect.  AFAIK there are no other differences besides
> the cifs-utils version.

Not counting any distro-specific patches it seems cifs.upcall only had 5
commits affecting it between these 2 releases:

  $ git log  --pretty=oneline cifs-utils-6.6...cifs-utils-6.4 cifs.upcall.c
  7852bec cifs.upcall: stop passing around ccache name strings
  39dbb7b cifs.upcall: make get_tgt_time take a ccache arg
  3db6b3a cifs.upcall: remove KRB5_TC_OPENCLOSE
  a3743af cifs.upcall: make the krb5_context a static global variable
  9be6e88 cifs.upcall: use krb5 routines to get default ccname

It seems the way cached credentials are searched changed, which your logs
show if you diff them:

  uid=0
  creduid=0
  user=[hidden email]
 -pid=27600
 -find_krb5_cc: scandir error on directory '/run/user/0': No such file or directory
 -find_krb5_cc: considering /tmp/krb5cc_0
 -find_krb5_cc: FILE:/tmp/krb5cc_0 is valid ccache
 -find_krb5_cc: considering /tmp/krb5cc_1494_sM11PG
 -find_krb5_cc: /tmp/krb5cc_1494_sM11PG is owned by 1494, not 0
 +pid=26578
 +get_tgt_time: unable to get principal
  handle_krb5_mech: getting service ticket for smb.physics.wisc.edu
  handle_krb5_mech: obtained service ticket
  Exit status 0

That "get_tgt_time: unable to get principal" message looks like it could
be related to "39dbb7b cifs.upcall: make get_tgt_time take a ccache
arg". Since you can easily reproduce the problem, if I were you I would
try to find the bad commits between those 5.

--
Aurélien Aptel / SUSE Labs Samba Team
GPG: 1839 CB5F 9F5B FB9B AA97  8C99 03C8 A49B 521B D5D3
SUSE Linux GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
Hi Aurélien,
   Thanks for the idea!
For Debian packages:
   6.4-1 works
   6.5-1 works
   6.5-2 works
   6.6-1 fails
   6.6-5 fails

So looks like something changed from 6.5 to 6.6...
When I have time I'll figure out how to compile the upcall binary.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
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 <[hidden email]>
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.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
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 <[hidden email]>
> 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 <[hidden email]>

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
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.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
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 <[hidden email]>
---
 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


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
On Fri, 2017-02-10 at 12:39 -0500, Jeff Layton wrote:

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

(cc'ing Nalin, Simo and the linux-cifs ml)

Yeah, it seems pretty likely that that is the problem. My guess is that
the extra stuff on the ccname is coming from pam_krb5, which seems to
want to create a credcache that is session-specific.

You could play with setting a different ccname_template for pam_krb5
that doesn't have the trailing stuff at the end, but it looks like it
won't clean them up on logout if you do that. Caveat emptor.

I'm not sure what the right solution is there. For Simo and Nalin:

The upshot here is that we did a big clean up of the cifs-utils code
recently, to get it out of the business of scanning /tmp for credcaches.
That allows us to have better compatibility with other credcache types
(keyring or whatever), and it was always rather nasty anyway.

pam_krb5 wants to make session-specific credcaches however, and
cifs.upcall can't easily guess them. cifs.upcall is called from the
kernel, so it can't look in the environment or anything to find the
credcache.

What's the right approach to fix this? Are we stuck with scanning /tmp
forever?
--
Jeff Layton <[hidden email]>

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
On Fri, 2017-02-10 at 14:14 -0500, Simo Sorce wrote:

> On Fri, 2017-02-10 at 13:30 -0500, Jeff Layton wrote:
> > On Fri, 2017-02-10 at 12:39 -0500, Jeff Layton wrote:
> > > 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?
> > >
> >
> > (cc'ing Nalin, Simo and the linux-cifs ml)
> >
> > Yeah, it seems pretty likely that that is the problem. My guess is
> > that
> > the extra stuff on the ccname is coming from pam_krb5, which seems to
> > want to create a credcache that is session-specific.
> >
> > You could play with setting a different ccname_template for pam_krb5
> > that doesn't have the trailing stuff at the end, but it looks like it
> > won't clean them up on logout if you do that. Caveat emptor.
> >
> > I'm not sure what the right solution is there. For Simo and Nalin:
> >
> > The upshot here is that we did a big clean up of the cifs-utils code
> > recently, to get it out of the business of scanning /tmp for
> > credcaches.
> > That allows us to have better compatibility with other credcache
> > types
> > (keyring or whatever), and it was always rather nasty anyway.
> >
> > pam_krb5 wants to make session-specific credcaches however, and
> > cifs.upcall can't easily guess them. cifs.upcall is called from the
> > kernel, so it can't look in the environment or anything to find the
> > credcache.
> >
> > What's the right approach to fix this? Are we stuck with scanning
> > /tmp
> > forever?
>
> I think the right approach in the long run will be the KCM we are
> building in SSSD and planning to make the default cache type for F26.
>
> For file ccaches you are out of luck, even scanning /tmp can fail as
> users can decide to put them elsewhere.
>
> If a scan need to be made I would rather stat the files and look which
> one belong to the user that start with "/tmp/krb" rather than trying to
> guess the file name. Keep in mind predictable file names in /tmp are
> really not an option so pam_krb5 is doing the right thing in using a
> randomized file name given it runs as root.
>

Well, that's what we used to do -- do a readdir in /tmp, start looking
for files that might be credcaches. Of course that meant we have to
carry around a bunch of cruft for handling FILE: credcaches that doesn't
really adapt well to DIR: or KEYRING: ones.

I guess I have a philosophical question: how is an application (like
cifs.upcall), which is not descended from the user's session expected to
find a user's credcache? Is that use-case just not really accounted for
buy the krb5 libs?

One thing we could do (though I really don't like it), is to take the
pid value passed in the upcall and scrape that task's
/proc/<pid>/environ file for KRB5CCNAME=. That really is pretty nasty
though.

--
Jeff Layton <[hidden email]>

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
In reply to this post by Samba - General mailing list
Hi Jeff,
   Got the log output you're looking for.  I think this is as you all
have suspected:

Feb 10 13:28:04 trog cifs.upcall: key description:
cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=0x5d6;creduid=0x5d6;pid=0x6725
Feb 10 13:28:04 trog cifs.upcall: ver=2
Feb 10 13:28:04 trog cifs.upcall: host=smb.physics.wisc.edu
Feb 10 13:28:04 trog cifs.upcall: ip=128.104.160.17
Feb 10 13:28:04 trog cifs.upcall: sec=1
Feb 10 13:28:04 trog cifs.upcall: uid=1494
Feb 10 13:28:04 trog cifs.upcall: creduid=1494
Feb 10 13:28:04 trog cifs.upcall: pid=26405
Feb 10 13:28:04 trog cifs.upcall: get_default_cc: default ccache is
FILE:/tmp/krb5cc_1494
Feb 10 13:28:04 trog cifs.upcall: get_tgt_time: unable to get principal
Feb 10 13:28:04 trog cifs.upcall: Exit status 1

Thanks,
Chad.

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
On Fri, 2017-02-10 at 13:33 -0600, Chad William Seys wrote:

> Hi Jeff,
>    Got the log output you're looking for.  I think this is as you all
> have suspected:
>
> Feb 10 13:28:04 trog cifs.upcall: key description:
> cifs.spnego;0;0;39010000;ver=0x2;host=smb.physics.wisc.edu;ip4=128.104.160.17;sec=krb5;uid=0x5d6;creduid=0x5d6;pid=0x6725
> Feb 10 13:28:04 trog cifs.upcall: ver=2
> Feb 10 13:28:04 trog cifs.upcall: host=smb.physics.wisc.edu
> Feb 10 13:28:04 trog cifs.upcall: ip=128.104.160.17
> Feb 10 13:28:04 trog cifs.upcall: sec=1
> Feb 10 13:28:04 trog cifs.upcall: uid=1494
> Feb 10 13:28:04 trog cifs.upcall: creduid=1494
> Feb 10 13:28:04 trog cifs.upcall: pid=26405
> Feb 10 13:28:04 trog cifs.upcall: get_default_cc: default ccache is
> FILE:/tmp/krb5cc_1494
> Feb 10 13:28:04 trog cifs.upcall: get_tgt_time: unable to get principal
> Feb 10 13:28:04 trog cifs.upcall: Exit status 1
>
> Thanks,
> Chad.

Yep, that's good in that it means that we at least understand the
problem. Now to figure out how to fix it...

--
Jeff Layton <[hidden email]>

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Samba - General mailing list
In reply to this post by Samba - General mailing list
On Fri, 2017-02-10 at 15:14 -0500, Simo Sorce wrote:

> On Fri, 2017-02-10 at 14:29 -0500, Jeff Layton wrote:
> > On Fri, 2017-02-10 at 14:14 -0500, Simo Sorce wrote:
> > > On Fri, 2017-02-10 at 13:30 -0500, Jeff Layton wrote:
> > > > On Fri, 2017-02-10 at 12:39 -0500, Jeff Layton wrote:
> > > > > 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?
> > > > >
> > > >
> > > > (cc'ing Nalin, Simo and the linux-cifs ml)
> > > >
> > > > Yeah, it seems pretty likely that that is the problem. My guess
> > > > is
> > > > that
> > > > the extra stuff on the ccname is coming from pam_krb5, which
> > > > seems to
> > > > want to create a credcache that is session-specific.
> > > >
> > > > You could play with setting a different ccname_template for
> > > > pam_krb5
> > > > that doesn't have the trailing stuff at the end, but it looks
> > > > like it
> > > > won't clean them up on logout if you do that. Caveat emptor.
> > > >
> > > > I'm not sure what the right solution is there. For Simo and
> > > > Nalin:
> > > >
> > > > The upshot here is that we did a big clean up of the cifs-utils
> > > > code
> > > > recently, to get it out of the business of scanning /tmp for
> > > > credcaches.
> > > > That allows us to have better compatibility with other credcache
> > > > types
> > > > (keyring or whatever), and it was always rather nasty anyway.
> > > >
> > > > pam_krb5 wants to make session-specific credcaches however, and
> > > > cifs.upcall can't easily guess them. cifs.upcall is called from
> > > > the
> > > > kernel, so it can't look in the environment or anything to find
> > > > the
> > > > credcache.
> > > >
> > > > What's the right approach to fix this? Are we stuck with scanning
> > > > /tmp
> > > > forever?
> > >
> > > I think the right approach in the long run will be the KCM we are
> > > building in SSSD and planning to make the default cache type for
> > > F26.
> > >
> > > For file ccaches you are out of luck, even scanning /tmp can fail
> > > as
> > > users can decide to put them elsewhere.
> > >
> > > If a scan need to be made I would rather stat the files and look
> > > which
> > > one belong to the user that start with "/tmp/krb" rather than
> > > trying to
> > > guess the file name. Keep in mind predictable file names in /tmp
> > > are
> > > really not an option so pam_krb5 is doing the right thing in using
> > > a
> > > randomized file name given it runs as root.
> > >
> >
> > Well, that's what we used to do -- do a readdir in /tmp, start
> > looking for files that might be credcaches. Of course that meant we
> > have to carry around a bunch of cruft for handling FILE: credcaches
> > that doesn't really adapt well to DIR: or KEYRING: ones.
> >
> > I guess I have a philosophical question: how is an application (like
> > cifs.upcall), which is not descended from the user's session expected
> > to find a user's credcache? Is that use-case just not really
> > accounted for buy the krb5 libs?
>
> Yeah it is not accounted for, it is assumed that applications are given
> a ccache name by the caller or in KRB5CCNAME.
> The fact the kernel operates this way was not on the radar in the
> intial design.
>
> > One thing we could do (though I really don't like it), is to take the
> > pid value passed in the upcall and scrape that task's
> > /proc/<pid>/environ file for KRB5CCNAME=. That really is pretty nasty
> > though.
>
> Yeah it is, and it is probably also not fully reliable, but it may be
> the best way to go in the short term.
>
> I think the only way will be the KCM, although it would be really nice
> if the KCM could be given a session id of some kind, because it would
> be nice to be able to have different ccaches in different sessions.
> However for the general case and NFS/CIFS in particular I think KCM
> will be the right way to go and will be sufficient to just talk to it
> "as the user" (ie with a setuid like nfs utils does).
>
> Simo.
>

Something like this might work (on top of the debug patch I sent
earlier). Only tested for compilation so far, but I think the approach
is fairly straightforward. It definitely needs testing, and I'm not sure
I really like trusting info in the user's environment like this. Any
thoughts on ways to vet it more carefully?

In any case, I'll plan to give this a spin over the weekend when I get
some time.

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

cifs.upcall: scrape KRB5CCNAME out of initiating task's /proc/<pid>/environ file

If we find one, then we use that to set the same variable, the same way in the
upcall's environment.

Signed-off-by: Jeff Layton <[hidden email]>
---
 cifs.upcall.c | 123 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 119 insertions(+), 4 deletions(-)

diff --git a/cifs.upcall.c b/cifs.upcall.c
index dd0843e358b1..82aa4f2c2c28 100644
--- a/cifs.upcall.c
+++ b/cifs.upcall.c
@@ -40,6 +40,7 @@
 #include <dirent.h>
 #include <sys/types.h>
 #include <sys/stat.h>
+#include <fcntl.h>
 #include <unistd.h>
 #include <keyutils.h>
 #include <time.h>
@@ -154,12 +155,127 @@ err_cache:
  return credtime;
 }
 
+#define CIFS_UPCALL_ENV_PATH_FMT "/proc/%d/environ"
+#define CIFS_UPCALL_ENV_PATH_MAXLEN (6 + 10 + 8 + 1)
+
+#define ENV_NAME "KRB5CCNAME"
+#define ENV_PREFIX "KRB5CCNAME="
+#define ENV_PREFIX_LEN 11
+
+#define ENV_BUF_START (4096)
+#define ENV_BUF_MAX (131072)
+
+/**
+ * get_cachename_from_process_env - scrape value of $KRB5CCNAME out of the
+ *    initiating process' environment.
+ * @pid: initiating pid value from the upcall string
+ *
+ * Open the /proc/<pid>/environ file for the given pid, and scrape it for
+ * KRB5CCNAME entries.
+ *
+ * We start with a page-size buffer, and then progressively double it until
+ * we can slurp in the whole thing.
+ *
+ * Note that this is not entirely reliable. If the process is sitting in a
+ * container or something, then this is almost certainly not going to point
+ * where you expect.
+ *
+ * Probably it just won't work, but could a user use this to trick cifs.upcall
+ * into reading a file outside the container, by setting KRB5CCNAME in a
+ * crafty way?
+ *
+ * YMMV here.
+ */
+static char *
+get_cachename_from_process_env(pid_t pid)
+{
+ int fd, ret;
+ ssize_t buflen;
+ ssize_t bufsize = ENV_BUF_START;
+ char pathname[CIFS_UPCALL_ENV_PATH_MAXLEN];
+ char *cachename = NULL;
+ char *buf = NULL, *pos;
+
+ if (!pid) {
+ syslog(LOG_DEBUG, "%s: pid == 0\n", __func__);
+ return NULL;
+ }
+
+ pathname[CIFS_UPCALL_ENV_PATH_MAXLEN - 1] = '\0';
+ ret = snprintf(pathname, CIFS_UPCALL_ENV_PATH_MAXLEN,
+ CIFS_UPCALL_ENV_PATH_FMT, pid);
+ if (ret || pathname[CIFS_UPCALL_ENV_PATH_MAXLEN - 1] != '\0') {
+ syslog(LOG_DEBUG, "%s: unterminated path!\n", __func__);
+ return NULL;
+ }
+
+ syslog(LOG_DEBUG, "%s: pathname=%s\n", __func__, pathname);
+ fd = open(pathname, O_RDONLY);
+ if (fd < 0) {
+ syslog(LOG_DEBUG, "%s: open failed: %d\n", __func__, errno);
+ return NULL;
+ }
+retry:
+ if (bufsize > ENV_BUF_MAX) {
+ syslog(LOG_DEBUG, "%s: buffer too big: %d\n", __func__, errno);
+ goto out_close;
+ }
+
+ buf = malloc(bufsize);
+ if (!buf) {
+ syslog(LOG_DEBUG, "%s: malloc failure\n", __func__);
+ goto out_close;
+ }
+
+ buflen = read(fd, buf, bufsize);
+ if (buflen < 0) {
+ syslog(LOG_DEBUG, "%s: read failed: %d\n", __func__, errno);
+ goto out_close;
+ }
+
+ if (buflen == bufsize) {
+ /* We read to the end of the buffer, double and try again */
+ syslog(LOG_DEBUG, "%s: read to end of buffer (%zu bytes)\n", __func__, bufsize);
+ free(buf);
+ bufsize *= 2;
+ if (lseek(fd, 0, SEEK_SET) < 0)
+ goto out_close;
+ goto retry;
+ }
+
+ pos = buf;
+ while (buflen > 0) {
+ size_t len = strnlen(pos, buflen);
+
+ if (len > ENV_PREFIX_LEN &&
+    memcmp(pos, ENV_PREFIX, ENV_PREFIX_LEN)) {
+ cachename = strndup(pos + ENV_PREFIX_LEN,
+ len - ENV_PREFIX_LEN);
+ syslog(LOG_DEBUG, "%s: cachename = %s\n", __func__, cachename);
+ break;
+ }
+ buflen -= (len + 1);
+ pos += (len + 1);
+ }
+ free(buf);
+out_close:
+ close(fd);
+ return cachename;
+}
+
 static krb5_ccache
-get_default_cc(void)
+get_existing_cc(pid_t pid)
 {
  krb5_error_code ret;
  krb5_ccache cc;
- char *cachename;
+ char *cachename = NULL;
+
+ cachename = get_cachename_from_process_env(pid);
+ if (cachename) {
+ if (setenv(ENV_NAME, cachename, 1))
+ syslog(LOG_DEBUG, "%s: failed to setenv %d\n", __func__, errno);
+ free(cachename);
+ }
 
  ret = krb5_cc_default(context, &cc);
  if (ret) {
@@ -182,7 +298,6 @@ get_default_cc(void)
  return cc;
 }
 
-
 static krb5_ccache
 init_cc_from_keytab(const char *keytab_name, const char *user)
 {
@@ -815,7 +930,7 @@ int main(const int argc, char *const argv[])
  goto out;
  }
 
- ccache = get_default_cc();
+ ccache = get_existing_cc(arg.pid);
  /* Couldn't find credcache? Try to use keytab */
  if (ccache == NULL && arg.username != NULL)
  ccache = init_cc_from_keytab(keytab_name, arg.username);
--
2.9.3


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Loading...