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 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. 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
