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

[Chad William Seys via samba]

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=smba...@PHYSICS.WISC.EDU --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=smba...@PHYSICS.WISC.EDU;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=smba...@PHYSICS.WISC.EDU
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=smba...@PHYSICS.WISC.EDU;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=smba...@PHYSICS.WISC.EDU
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=smba...@PHYSICS.WISC.EDU;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=smba...@PHYSICS.WISC.EDU
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=smba...@PHYSICS.WISC.EDU;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=smba...@PHYSICS.WISC.EDU
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

[Aurélien Aptel via samba]

Chad William Seys via samba <sa...@lists.samba.org> 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=smba...@PHYSICS.WISC.EDU
-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)

[Chad William Seys via samba]

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.

[Chad William Seys via samba]

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

[Jeff Layton via samba]

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 <jla...@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 <jla...@samba.org>

[Chad William Seys via samba]

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.

[Jeff Layton via samba]

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

[Jeff Layton via samba]

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 <jla...@samba.org>

[Chad William Seys via samba]

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.

[Jeff Layton via samba]

On Fri, 2017-02-10 at 14:14 -0500, Simo Sorce wrote:

> 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 via samba]

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 <jla...@samba.org>

[Jeff Layton via samba]

On Fri, 2017-02-10 at 15:14 -0500, Simo Sorce wrote:

> 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 <jla...@samba.org>
---

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