On Tue, Jun 9, 2009 at 3:10 PM, Steve Dickson<SteveD@xxxxxxxxxx> wrote: > > > Kevin Coffman wrote: >> On Fri, Jun 5, 2009 at 2:57 PM, Steve Dickson<SteveD@xxxxxxxxxx> 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. Hi Steve, To kick off the [delegation] callback, a user on the client has to do an open after the mount. The first open from a client should cause the server to try to establish the callback to that client machine. Failure to establish the callback shouldn't cause anything to fail, (there just won't be delegations). However, without gssd running on the server, the upcall failure (timeout) will be logged as I noted. K.C. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
