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 [email protected]
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
*********************************************************************************
On Mon, 30 Sep 2013 11:00:13 -0400
"J. Bruce Fields" <[email protected]> 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 <[email protected]> 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 <[email protected]>
On Mon, 30 Sep 2013 13:06:47 +0100
Michael Gliwinski <[email protected]> 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 <[email protected]>
On Mon, 30 Sep 2013 11:00:13 -0400
"J. Bruce Fields" <[email protected]> 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 <[email protected]> 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 <[email protected]>
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 <[email protected]>
On Mon, Sep 30, 2013 at 10:00:00AM -0400, Jeff Layton wrote:
> On Mon, 30 Sep 2013 13:06:47 +0100
> Michael Gliwinski <[email protected]> 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 <[email protected]>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html