On Tue, Sep 03, 2013 at 11:11:54PM -0400, Simo Sorce wrote: > On Mon, 2013-08-26 at 12:50 -0400, J. Bruce Fields wrote: > > > > > Also the patch seem to add a bunch of other 'service' names ? If > > you are > > > > > going to kerberize those services are you going to expect admins > > to drop > > > > > multiple keys down in the keytabs ? What is the exact intent > > here ? > > > > Yeah, that seems wrong to me, if (big if) any of the other services > > used gss I'd expect they'd want to authenticate to the same nfs/ > > principal. > > > > > > Mostly, I'm trying to ensure that the nfsacl service uses a nfs/ > > > > principal to fix the immediate pain point that nfsv3+krb5 doesn't > > work. > > > > With the rest, I was mainly trusting that Trond knew what he was > > > > doing. ;) > > > > > > > > I agree though...I've never seen a nfs4_cb/ principal in use, and > > I'm > > > > not sure that we'd really get a lot of value from using a separate > > > > principal for callbacks. > > > > > > It's wrong, in fact: an NFSv4.0 callback is supposed to authenticate > > to > > > the principal that performed the setclientid. > > > > Well, but: after refamiliarizing myself with the code this morning: > > really, it's irrelevant. The server's setup_callback_client() calls > > rpc_create with client_name set to the principal that performed the > > setclientid. This sets cl_principal, which results in a "target=" > > argument in the upcall. > > > > (The way this is set looks hairy: > > > > - svcgssd case: svcgssd passes it down at the end of the > > downcall. It's calculated by > > utils/gssd/svcgssd_proc.c:get_hostbased_client_name by > > calling > > gss_display_name() and then changing x/y@REALM to x@y in the > > krb5 case. ?? > > - gssproxy case: does the same transformation on the returned > > name in gssp_accept_sec_context_upcall. > > > > But Simo'd be the expert on whether this makes sense and what we > > should do instead if not.) > > The way this is done make little sense, and I guess it is probably > historical due to some deficiency in GSSAPI extensions at the time or > knowledge of whoever was building the support. > > GSSAPI uses by default service@server form for the target service name > but it is not the only way to import a name. If you are going to force > the usage of the krb5 mechanism (as we are) then we could have simply > exported the name (gives a buffer) and then re-imported back later. > > In any case it is what it is, I think it makes little sense in principle > to try to 'contact back' the 'client' principal that authenticated Well, that part at least is required by the spec, unless I've misread something. (RFC 3530 section 3.4.) > as > that principal may even be a user principal and you'll probably not be > able to get a ticket to talk to 'it' and the receiving server will > probably not have keys to understand your ticket even if you got one. So if you want delegations to work you're expected to give the client a principal that the server can authenticate back to. (Delegations are the only NFSv4.0 feature that depend on callbcks.) --b. > > TL;DR it kinda sucks but it is not worth changing much except for using > only 'nfs' as the service type and nothing else. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- > 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 -- 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
