Re: [PATCH v3] SUNRPC: Ensure that the RPCSEC_GSS daemon uses the correct service names

["J. Bruce Fields" <bfields@fieldses.org>]

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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html