* gss context cache
@ 2013-09-30 12:06 Michael Gliwinski
2013-09-30 14:00 ` Jeff Layton
0 siblings, 1 reply; 5+ messages in thread
From: Michael Gliwinski @ 2013-09-30 12:06 UTC (permalink / raw)
To: Linux NFS Mailing list
Hi all,
On RHEL6 nfs-utils-1.2.3-36
man rpc.gssd says it -t wasn't specified then kernel gss contexts will be
cached for the lifettime of the Kerberos service ticket used in its creation.
Is there a way to see the contexts + service tickets in that cache?
Also, is there any way short of rebooting the client to evict one entry from
that cache, or even clear the cache entirely?
(looking for this as I had situations where access was denied by the NFS
server and I could see the principal was getting mapped to nfsnobody, etc. and
was suspecting the account was changed on the KDC and the old context/ticket
may have been causing problems)
Thanks,
Michael
**********************************************************************************************
The information in this email is confidential and may be legally privileged. It is intended solely for the addressee and access to the email by anyone else is unauthorised.
If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
When addressed to our clients, any opinions or advice contained in this e-mail are subject to the terms and conditions expressed in the governing client engagement leter or contract.
If you have received this email in error please notify support@henderson-group.com
John Henderson (Holdings) Ltd
Registered office: 9 Hightown Avenue, Mallusk, County Antrim, Northern Ireland, BT36 4RT.
Registered in Northern Ireland
Registration Number NI010588
Vat No.: 814 6399 12
*********************************************************************************
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gss context cache
2013-09-30 12:06 gss context cache Michael Gliwinski
@ 2013-09-30 14:00 ` Jeff Layton
2013-09-30 15:00 ` J. Bruce Fields
0 siblings, 1 reply; 5+ messages in thread
From: Jeff Layton @ 2013-09-30 14:00 UTC (permalink / raw)
To: Michael Gliwinski; +Cc: Linux NFS Mailing list
On Mon, 30 Sep 2013 13:06:47 +0100
Michael Gliwinski <Michael.Gliwinski@henderson-group.com> wrote:
> Hi all,
>
> On RHEL6 nfs-utils-1.2.3-36
>
> man rpc.gssd says it -t wasn't specified then kernel gss contexts will be
> cached for the lifettime of the Kerberos service ticket used in its creation.
> Is there a way to see the contexts + service tickets in that cache?
>
No, AFAIK.
> Also, is there any way short of rebooting the client to evict one entry from
> that cache, or even clear the cache entirely?
>
There is a gss_destroy_creds script which ships as part of nfs-utils.
That should basically do what you need, but it's not well-documented so
you'll have to play with it some...
> (looking for this as I had situations where access was denied by the NFS
> server and I could see the principal was getting mapped to nfsnobody, etc. and
> was suspecting the account was changed on the KDC and the old context/ticket
> may have been causing problems)
>
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gss context cache
2013-09-30 14:00 ` Jeff Layton
@ 2013-09-30 15:00 ` J. Bruce Fields
2013-09-30 15:53 ` Jeff Layton
2013-09-30 18:04 ` Jeff Layton
0 siblings, 2 replies; 5+ messages in thread
From: J. Bruce Fields @ 2013-09-30 15:00 UTC (permalink / raw)
To: Jeff Layton; +Cc: Michael Gliwinski, Linux NFS Mailing list
On Mon, Sep 30, 2013 at 10:00:00AM -0400, Jeff Layton wrote:
> On Mon, 30 Sep 2013 13:06:47 +0100
> Michael Gliwinski <Michael.Gliwinski@henderson-group.com> wrote:
>
> > Hi all,
> >
> > On RHEL6 nfs-utils-1.2.3-36
> >
> > man rpc.gssd says it -t wasn't specified then kernel gss contexts will be
> > cached for the lifettime of the Kerberos service ticket used in its creation.
> > Is there a way to see the contexts + service tickets in that cache?
> >
>
> No, AFAIK.
>
> > Also, is there any way short of rebooting the client to evict one entry from
> > that cache, or even clear the cache entirely?
> >
>
> There is a gss_destroy_creds script which ships as part of nfs-utils.
> That should basically do what you need, but it's not well-documented so
> you'll have to play with it some...
My memory is that depended on some undocumented feature of the upcall
since removed. (Maybe the ability to send a downcall that isn't a
response to some upcall?) But I may be misremembering. Somebody should
probably check and remove that script (and gss_cltn_send_err) if I'm
right.
--b.
>
> > (looking for this as I had situations where access was denied by the NFS
> > server and I could see the principal was getting mapped to nfsnobody, etc. and
> > was suspecting the account was changed on the KDC and the old context/ticket
> > may have been causing problems)
> >
>
>
> --
> Jeff Layton <jlayton@redhat.com>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gss context cache
2013-09-30 15:00 ` J. Bruce Fields
@ 2013-09-30 15:53 ` Jeff Layton
2013-09-30 18:04 ` Jeff Layton
1 sibling, 0 replies; 5+ messages in thread
From: Jeff Layton @ 2013-09-30 15:53 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Michael Gliwinski, Linux NFS Mailing list
On Mon, 30 Sep 2013 11:00:13 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Mon, Sep 30, 2013 at 10:00:00AM -0400, Jeff Layton wrote:
> > On Mon, 30 Sep 2013 13:06:47 +0100
> > Michael Gliwinski <Michael.Gliwinski@henderson-group.com> wrote:
> >
> > > Hi all,
> > >
> > > On RHEL6 nfs-utils-1.2.3-36
> > >
> > > man rpc.gssd says it -t wasn't specified then kernel gss contexts will be
> > > cached for the lifettime of the Kerberos service ticket used in its creation.
> > > Is there a way to see the contexts + service tickets in that cache?
> > >
> >
> > No, AFAIK.
> >
> > > Also, is there any way short of rebooting the client to evict one entry from
> > > that cache, or even clear the cache entirely?
> > >
> >
> > There is a gss_destroy_creds script which ships as part of nfs-utils.
> > That should basically do what you need, but it's not well-documented so
> > you'll have to play with it some...
>
> My memory is that depended on some undocumented feature of the upcall
> since removed. (Maybe the ability to send a downcall that isn't a
> response to some upcall?) But I may be misremembering. Somebody should
> probably check and remove that script (and gss_cltn_send_err) if I'm
> right.
>
Thanks, good to know. I have some other work on my plate for gssd in the
near future, so I'll plan to have a look at that as well.
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: gss context cache
2013-09-30 15:00 ` J. Bruce Fields
2013-09-30 15:53 ` Jeff Layton
@ 2013-09-30 18:04 ` Jeff Layton
1 sibling, 0 replies; 5+ messages in thread
From: Jeff Layton @ 2013-09-30 18:04 UTC (permalink / raw)
To: Michael Gliwinski; +Cc: J. Bruce Fields, Linux NFS Mailing list
On Mon, 30 Sep 2013 11:00:13 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:
> On Mon, Sep 30, 2013 at 10:00:00AM -0400, Jeff Layton wrote:
> > On Mon, 30 Sep 2013 13:06:47 +0100
> > Michael Gliwinski <Michael.Gliwinski@henderson-group.com> wrote:
> >
> > > Hi all,
> > >
> > > On RHEL6 nfs-utils-1.2.3-36
> > >
> > > man rpc.gssd says it -t wasn't specified then kernel gss contexts will be
> > > cached for the lifettime of the Kerberos service ticket used in its creation.
> > > Is there a way to see the contexts + service tickets in that cache?
> > >
> >
> > No, AFAIK.
> >
> > > Also, is there any way short of rebooting the client to evict one entry from
> > > that cache, or even clear the cache entirely?
> > >
> >
> > There is a gss_destroy_creds script which ships as part of nfs-utils.
> > That should basically do what you need, but it's not well-documented so
> > you'll have to play with it some...
>
> My memory is that depended on some undocumented feature of the upcall
> since removed. (Maybe the ability to send a downcall that isn't a
> response to some upcall?) But I may be misremembering. Somebody should
> probably check and remove that script (and gss_cltn_send_err) if I'm
> right.
>
That appears to be correct. gss_clnt_send_err just does an unsolicited
downcall to the given clnt directory for a given uid. AFAICT, that
functionality was ripped out by this commit:
commit 3b68aaeaf54065e5c44583a1d33ffb7793953ba4
Author: Trond Myklebust <Trond.Myklebust@netapp.com>
Date: Thu Jun 7 10:14:15 2007 -0400
SUNRPC: Always match an upcall message in gss_pipe_downcall()
...so Bruce appears to be correct and this command no longer serves any
purpose. I'll spin up a patch to remove it.
Michael, you can disregard my earlier suggestion to use it....
--
Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-09-30 18:04 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-30 12:06 gss context cache Michael Gliwinski
2013-09-30 14:00 ` Jeff Layton
2013-09-30 15:00 ` J. Bruce Fields
2013-09-30 15:53 ` Jeff Layton
2013-09-30 18:04 ` Jeff Layton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).