Samba3's fake GSSAPI and FreeBSD

[simo]

On Wed, 2010-09-15 at 08:35 +1000, Andrew Bartlett wrote:
> On Mon, 2010-09-13 at 11:51 -0400, simo wrote: 
> > On Mon, 2010-09-13 at 09:56 +1000, Andrew Bartlett wrote:
> > > On Sun, 2010-09-12 at 09:24 -0400, simo wrote:
> > > > On Sun, 2010-09-12 at 16:08 +1000, Andrew Bartlett wrote:
> > > > > On Sat, 2010-09-11 at 18:59 -0700, Jeremy Allison wrote:
> > > > > > On Sat, Sep 11, 2010 at 07:01:16PM +1000, Andrew Bartlett wrote:
> > > > > > 
> > > > > > > Samba4 will cope with the previous behaviour (a normal krb5 checksum
> > > > > > > without a gssapi channel binding), and with a full gssapi channel
> > > > > > > binding, but not this particular combination.
> > > > > > 
> > > > > > Unfortunately Windows doesn't, and requres the checksum.
> > > > > 
> > > > > That's interesting - what I meant is that Windows and Samba4 (Heimdal)
> > > > > accepted the 3.0 behaviour, where we had the normal krb5 checksum type,
> > > > > and no data (because it's not gssapi, so no bindings to sum).  The
> > > > > variations after that I'm less clear on. 
> > > > > 
> > > > > > > As this is all well
> > > > > > > outside real GSSAPI behaviour, I've put this change in to keep
> > > > > > > everything consistent.
> > > > > > > 
> > > > > > > http://gitweb.samba.org/?p=samba.git;a=commitdiff;h=3b4db34011f06fb785153fa9070fb1da9d8f5c78
> > > > > > 
> > > > > > Ok, that makes sense. Please apply to v3-6-test as well please.
> > > > > 
> > > > > Sure.  
> > > > > 
> > > > > > > Perhaps we should perhaps have two simple defines:  HAVE_KRB5 and
> > > > > > > HAVE_MODERN_KRB5, with a switch between the two rather than testing for
> > > > > > > each function, and getting too many combinations.  We just can't test
> > > > > > > the number of variations at the moment.  
> > > > > > > 
> > > > > > > In the long term, I very much look forward to replacing this with real
> > > > > > > GSSAPI at some point, and removing much of this complexity.
> > > > > > 
> > > > > > Sure, Simo is working on this at the moment.
> > > > > 
> > > > > Simo,
> > > > > 
> > > > > I would like to work with you on this, if you are able. 
> > > > 
> > > > If you want to review the work being done in my msrpc branch, feel free
> > > > to send comments. I am going to push it very soon, as most of my test
> > > > scenarios sem to pass.
> > > 
> > > This looks like a very useful set of changes!  It also looks to me like
> > > you have removed much of the DCE/RPC specific stuff from the
> > > authentication code here, and so we have the hope that we could use the
> > > same code in the SASL and CIFS servers too. 
> > 
> > Yes, I explicitly and consciously made an effort to make it dcerpc
> > independent, so that we can think of using it ofr CIFS. Haven't looked
> > at SASL, but should be easy to model it like the SPNEGO wrappers.
> > 
> > > Is the client code here too?  It's not very clear from the commits.
> > 
> > The client code is already in master.
> > 
> > > I'm keen to extend this - is there a particular area I could work on
> > > that would help, without getting in your way?
> > 
> > Before extending it to CIFS/SASL we need review and testing in order to
> > be able to commit this code to master.
> > 
> > There is one problem with setting up the credentials that depends on the
> > fact that the MIT GSSAPI interface has some issues internally.
> > They are being resolved and a new interface similar to that of Heimdal
> > is being introduced to import credentials directly from a kerberos
> > context.
> > But it will not be in any distribution/OS for a long time so we need to
> > work around it.
> > But that problem may go away if we unify all the code to set up the
> > server credentials in only one place.
> 
> OK.  That should have us looking more like a standard krb5 service, and
> hopefully fit into the 'expected use' modal. 
> 
> > Another problem is that some of this code depends on facilities not
> > available in MIT until 1.7/1.8. this is what prevents us from actually
> > using it in CIFS as it would mean a regression (no krb5 support) for
> > many platforms that has only older versions available.
> > We never had krb5 support for DCERPC so I didn't feel constrained to
> > provide backward compatible support in there. But if we want to make
> > smbd use this code we need someone to make this code work on older
> > Kerberos versions first.
> 
> In s3compat we showed that we could build Samba3 against the embedded
> Heimdal.  Once we get a common WAF, it would be very useful to build
> against this anyway (to allow 'make test' to run Kerberos calls against
> Samba4, using socket_wrapper).  
> 
> Could we have an arrangement where we build against an included Heimdal
> for development testing, and for platforms without a recent enough
> library, but use the system lib on modern distributions like Fedora and
> Ubuntu?
> 
> That way, we would stop having optional features, and simply choose the
> best method to provide those features on a given platform. 

Sorry, not an option for me.
Our platform ships with MIT kerberos and that's what we need to use.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>