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

[Jeff Layton <jlayton@redhat.com>]

On Wed, 4 Sep 2013 13:49:59 -0400
"J. Bruce Fields" <bfields@fieldses.org> wrote:

> On Wed, Sep 04, 2013 at 01:21:53PM -0400, Simo Sorce wrote:
> > 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:
> > > > > 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...
> 
> Right, this got fixed in NFSv4.1.
> 
> So I'm just describing the legacy responsibility to keep NFSv4.0
> callbacks working in those cases where they can, to prevent regressions
> for 4.0 users whose setups do meet the requirements.
> 
> --b.
> 
> > 
> > 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
> > 

...and off-topic a bit here, but I think we can just drop this patch
now. It looks like the patch series that Trond posted on Monday fixes
this bug.

-- 
Jeff Layton <jlayton@redhat.com>