From: Steve Dickson <SteveD@redhat.com>
To: Kevin Coffman <kwc@citi.umich.edu>
Cc: linux-nfs@vger.kernel.org
Subject: Re: [round2 PATCH 0/7] nfs-utils: add support for authenticated callbacks
Date: Tue, 09 Jun 2009 15:10:52 -0400 [thread overview]
Message-ID: <4A2EB3BC.8040802@RedHat.com> (raw)
In-Reply-To: <4d569c330906051247y7e24a7d4q3392b1481954447c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Kevin Coffman wrote:
> On Fri, Jun 5, 2009 at 2:57 PM, Steve Dickson<SteveD@redhat.com> wrote:
>> Kevin Coffman wrote:
>>> Hi Steve,
>>>
>>> This series adds support to gssd and svcgssd to support
>>> authenticated callbacks.
>>>
>>> 1) adds the name the client used when authenticating to the
>>> svcgssd downcall information. This is used by nfsd to determine
>>> the target name when initiating the callback.
>>>
>>> 2) splits out the processing of update_client_list() to accomodate
>>> a new upcall pipe added in the next patch.
>>>
>>> 3) changes gssd to process all rpc_pipefs directories (this patch is
>>> changed from the first round to process all directories rather than
>>> special-casing directories)
>>>
>>> 4) a debugging aid to distinquish which upcall is being processed
>>>
>>> 6) adds support for handling the "target=" attribute in the new upcall
>>>
>>> 7) adds support for handling the "service=" attribute in the new upcall
>>>
>>> NOTE: For authenticated callbacks to work, an NFS client or an
>>> NFS server must be running both rpcgssd _and_ rpcsvcgssd.
>>> This will require a configuration change.
>> Question, How are authenticated callbacks are not configured?
>> Also do both daemons have to be running if authenticated
>> callbacks are not configured?
>>
>> steved.
>
> Hi Steve,
> AFAIK, there isn't a way to turn off the attempt to do the
> authenticated callback. I think that's what you mean by how are they
> not configured?
>
> So for example, if the nfs client is not running svcgssd, the server
> will attempt the callback (with authentication), and the upcall
> request will time out and fail. If the NFS server is not running
> gssd, when it attempts to establish the callback its upcall to gssd
> will time out and you'll get the printks warning that the daemon is
> not running.
hmm... I'm unable to see these failures you are talking about which is
a good thing, but It also means I'm probably not understanding something...
Question: when these request time out happen, will they cause the krb5
mount to fail or access denied to users with valid krb5 tickets?
steved.
next prev parent reply other threads:[~2009-06-09 19:13 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-20 15:20 [round2 PATCH 0/7] nfs-utils: add support for authenticated callbacks Kevin Coffman
[not found] ` <20090520151651.2986.29621.stgit-zTNJhAanYLVZN1qrTdtDg5Vzexx5G7lz@public.gmane.org>
2009-05-20 15:20 ` [round2 PATCH 1/7] svcgssd: add client's principal name to downcall information Kevin Coffman
2009-05-20 15:20 ` [round2 PATCH 2/7] gssd: refactor update_client_list() Kevin Coffman
2009-05-20 15:20 ` [round2 PATCH 3/7] gssd: add upcall support for callback authentication Kevin Coffman
2009-05-20 15:20 ` [round2 PATCH 4/7] gssd: print full client directory being handled Kevin Coffman
2009-05-20 15:21 ` [round2 PATCH 5/7] gssd: handle new client upcall Kevin Coffman
2009-05-20 15:21 ` [round2 PATCH 6/7] gssd: process target= attribute in new upcall Kevin Coffman
2009-05-20 15:21 ` [round2 PATCH 7/7] gssd: process service= " Kevin Coffman
2009-06-05 18:57 ` [round2 PATCH 0/7] nfs-utils: add support for authenticated callbacks Steve Dickson
[not found] ` <4A296A95.3070208-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-06-05 19:47 ` Kevin Coffman
[not found] ` <4d569c330906051247y7e24a7d4q3392b1481954447c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-06-09 19:10 ` Steve Dickson [this message]
[not found] ` <4A2EB3BC.8040802-AfCzQyP5zfLQT0dZR+AlfA@public.gmane.org>
2009-06-09 21:43 ` Kevin Coffman
2009-11-16 17:29 ` Steve Dickson
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=4A2EB3BC.8040802@RedHat.com \
--to=steved@redhat.com \
--cc=kwc@citi.umich.edu \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.