public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Lukas Hejtmanek <xhejtman@ics.muni.cz>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfsv4@linux-nfs.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/2] use negative cache for Kerberos credentials
Date: Mon, 3 May 2010 15:47:36 +0200	[thread overview]
Message-ID: <20100503134736.GA18765@ics.muni.cz> (raw)
In-Reply-To: <1269271124.3496.4.camel@localhost.localdomain>

Hi,

On Mon, Mar 22, 2010 at 11:18:44AM -0400, Trond Myklebust wrote:
> We already have code in nfs4proc.c for handling EKEYEXPIRED, and that
> delays the request before allowing it to retry. What I was proposing was
> negative caching, so that if some other process comes along and tries to
> do an upcall, the RPC code just immediately returns EKEYEXPIRED instead
> of asking gssd again.
> 
> Something like the following (still untested) patch.

we tested the patch and found the following.

Assume, we mounted NFS volume somewhere, we are non root user and we have
valid kerberos ticket. We access the volume. 

The following sequence of procedures is called:

gss_lookup_cred - search, whether we have the ticket
gss_cred_init - create a new ticket into cache (according to
gss_pipe_downcall)
gss_pip_downcall - calls rpc.gssd
gss_marchal
gss_wrap_req
gss_validate
gss_unwrap_resp
nfs4_handle_exception: 0 - OK, we got the ticket

If the ticket is valid and has been found in cache:
gss_lookup_cred
gss_match
gss_wrap_req
gss_validate
gss_unwrap_resp
nfs4_handle_exception: 0 - OK, we got the ticket

Now, the ticket expired.

gss_lookup_cred
gss_match
gss_marshal
gss_wrap_req
gss_refresh
gss_renew_cred
gss_lookup_cred
gss_match
gss_match
gss_destroy_cred
gss_pipe_downcall
gss_destroy_cred
nfs4_handle_exeption: ticket expired

second try to access NFS with an expired ticket

gss_lookup_cred
gss_cred_init
gss-pipe_downcall
gss_destroy_cred
nfs4_handle_exception: ticket expired

another try, no gss_refresh is called until a new ticket is available.

Your patch seems the gss_refresh to be called to work properly.

So, the first process accessing the NFS volume without ticket gets stopped.
But the others are not. 

And there is no difference how many times the application tried to access the
NFS4 volume.

I think, it is useful if you do:
ls /mnt/nfs4
return immediately if you don't have a ticket or the ticked is expired.

But if the application spin fast, stop it. 

What is your opinion how to solve this?

We are thinking about to move the negative cache into another function, i.e.,
the function that gets called. Or create different negative cache for this
purpose. Or fill fake tickets into cache and catch them.

What's your idea? We can develop it but we are not about to develop something
that would be refused as our previous work.

-- 
Lukáš Hejtmánek

      reply	other threads:[~2010-05-03 13:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20100316115439.GX19154@ics.muni.cz>
     [not found] ` <1268745962.3155.25.camel@localhost.localdomain>
     [not found]   ` <20100316162738.GD19154@ics.muni.cz>
     [not found]     ` <1268758702.3098.8.camel@localhost.localdomain>
     [not found]       ` <20100322094731.GO18907@ics.muni.cz>
2010-03-22 15:18         ` [PATCH 1/2] use negative cache for Kerberos credentials Trond Myklebust
2010-05-03 13:47           ` Lukas Hejtmanek [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100503134736.GA18765@ics.muni.cz \
    --to=xhejtman@ics.muni.cz \
    --cc=linux-nfs@vger.kernel.org \
    --cc=nfsv4@linux-nfs.org \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox