[cifs-utils PATCHv2 0/6] cifs.upcall: cleanup and overhaul of the cifs.upcall krb5 handling code

[Simo]

On Thu, 2016-08-25 at 16:51 -0400, Jeff Layton wrote:
> On Thu, 2016-08-25 at 22:59 +0300, Isaac Boukris wrote:
> > 
> > On Thu, Aug 25, 2016 at 7:44 PM, Jeff Layton <jlayton at samba.org>
> > wrote:
> > > 
> > > 
> > > On Thu, 2016-08-25 at 19:05 +0300, Isaac Boukris wrote:
> > > > 
> > > > 
> > > > However, it gets more complicated when it comes to SPNEGO.
> > > > First, when I call gss_init_sec_context with SPNEGO mech it
> > > > will
> > > > always return GSS_S_CONTINUE_NEEDED as it need server response
> > > > in
> > > > order to complete (even if mutual auth is not requested).
> > > > This causes (I think) the call to
> > > > gss_inquire_sec_context_by_oid
> > > > to
> > > > fail.
> > > > Also, we need to support continuation anyway for mutual auth
> > > > and
> > > > NTLM
> > > > fallback.
> > > > 
> > > Ahh that's interesting. I didn't realize we'd be stuck having to
> > > handle
> > > a multi-stage negotiation if we use gss_init_sec_context. That is
> > > sort
> > > of difficult to handle with the way the upcall currently works.
> > > 
> > > I may still play with it just to verify that I understand what
> > > you're
> > > saying but it does make sense.
> > 
> > You may take look at my (dirty) draft:
> > https://github.com/frenche/cifs-utils/tree/gssapi_upcall
> > 
> Neat. Do you have a companion kernel patch? I'm wondering about how
> to
> handle backward compatibility there. I guess we could try SPNEGO
> first
> and fall back to using the *KRB5 if that fails.
> 
> Another thing (not directly related) that I've been considering is
> whether we can use anonymous krb5 creds to handle the initial mount
> for
> sec=krb5 mounts. It would be nice to be able to do multiuser mounts
> without any client side setup.

You could use the workstation credentials if you are joined to a
domain, but even better would be to let gss-proxy decide it by telling
it you are acting as the "root" user, or passing an option in the gss-
proxy protocol.

Really please let's not add another half-assed "gssapi upcall mechanism
here".

> > 
> > > 
> > > 
> > > If we're going to go down the road of changing the upcall to
> > > handle
> > > that then I think I'd prefer to just change cifs.ko over to use
> > > gssproxy directly, like knfsd already does.
> > > 
> > > It would be one less special snowflake to deal with and most of
> > > the
> > > plumbing is already in place. We could leave the old upcall in
> > > place
> > > for legacy userland case, and only do it if the gssproxy
> > > negotiation
> > > failed. It's a bit of a project, but would be totally doable.
> > 
> > The cifs kernel module will need some changes anyway to handle
> > multi-stage negotiation I think.
> > Using gssproxy sounds like an excellent idea, though I'm only
> > vaguely
> > familiar with it so I'll have to look it up.
> > 
> > On the other hand I think there may still be an interest for
> > stateless
> > mechanism (alongside) which wouldn't require a running daemon.
> > I'm trying to think of an alternative to exporting the gss context,
> > perhaps by keeping the upcall process running and continuing the
> > conversation with the kernel module somehow.
> >  
> Yeah, not having a running daemon is certainly simpler for users. 

Although it may be simpler it makes little sense, in most cases when
you use kerberos you are probably joined to a domain and already have
winbindd or sssd running, and kerberos/gssapi is complex enough that
having to run a daemon is not a big deal.
However you could always try to start the gssproxy daemon if it is not
running. It won't do much good if it has no configuration, however
distributions that allow to start it via the kernel could make sure to
have defaults that would work as well as any upcall mechanism you can
come up with.

I say this because we are working to add more and more features to the
system to handle GSSAPI well, both for krb5 and NTLM protocols, and
other less known ones eventually, and doing it in one place and
avoiding duplications everywhere would concentrate efforts and get you
expert help, as well as a consistent experience across protocols (both
nfs and cifs).

Simo.