On Wed, 2013-09-04 at 09:39 -0400, J. Bruce Fields wrote: > 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.) In many deployments this is not possible, so the original specification is unrealistic. If the client already has a channel open with the server, why on earth the server does not just reuse that channel to send back messages ? Why it is trying a call 'back' ? Callbacks are notoriously broken, they do not work when clients do not have a service principal, and if you are actually trying to open a TCP socket back it will break if a client is behind a NAT or has a strict firewall in front of it and so on and so forth... I hoped people stopped using callbacks for this type of operations long ago when Microsoft experimented with this bad idea in the 90ies with the CIFS protocol and gave up (they tried to use callback for printing for example). 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
