The road to add support for MIT Kerberos to be able to release Samba 4.0

[Andrew Bartlett]

On Tue, 2012-05-08 at 15:25 -0400, simo wrote:
> On Tue, 2012-05-08 at 12:40 +1000, Andrew Bartlett wrote: 
> > On Mon, 2012-05-07 at 08:57 -0400, simo wrote:
> > > Hi all,
> > > I and Alexander have been working on a document that explains how/why we
> > > are working on getting MIT Kerberos support for Samba 4 builds for at
> > > least all the non-DC parts of Samba.
> > > The (K)DC part cannot be implemented as easily so we decided to not
> > > consider it a blocker for a 4.0 release although very highly desirable
> > > for a 4.1 build.
> > > 
> > > Please see about it here:
> > > https://wiki.samba.org/index.php/MIT_Build
> > 
> > Simo,
> > 
> > Thank you very much for writing this down.  I wish you the very best
> > with the patches you are preparing, and appreciate you letting me review
> > them - I have found that very helpful.
> > 
> > There seems to be 3 key issues that you raise on that page:
> >  - Making Samba's top level build compile with MIT Kerberos (for client
> > libraries at least)
> >  - Allowing distributors to ship portions of Samba (potentially in
> > different packages), and reducing the 'unnecessary' dependencies of some
> > of those portions
> >  - Building without any Heimdal-derived code what-soever. 
> > 
> > I see these as being in decreasing order of importance - that is,
> > clearly it is critical for you (but not, in my view a blocker for a 4.0
> > release if you cannot achieve it) to separate your distribution of Samba
> > from Heimdal.  I've seen you write often about your concerns here, the
> > most concrete being incompatible ccache formats for S4U2Proxy. 
> 
> The first is a blocker, the second debatable but probably not.
> The third is part of the first when it comes to client libraries.
> 
> > That said, you state:
> > > It is impossible to confidently segregate two libraries with
> > > conflicting symbols unless static linking or full symbol renaming
> > > techniques are employed. Neither is done in current Samba code.
> > 
> > Could you perhaps include a reference to a real-world failure of the
> > symbol versioning?  It would help us either deal with it, or at least
> > document it for future understanding.
> 
> Alexander posted a clear example in march to samba-technical:
> https://lists.samba.org/archive/samba-technical/2012-March/082130.html
> 
> This is what raised the urgency from we should do it, to we *have to* do
> it.

I thought that
https://lists.samba.org/archive/samba-technical/2012-March/082131.html
indicated that Alexander called an undeclared function?

> > As to the issues with dependencies in the waf build, this seems to be
> > mostly an issue if you wish to ship only parts of Samba.  While some
> > dependencies are easily resolved (such as the way the exportkeytab code
> > was moved out of libnet, avoiding a dependency on the KDC which you
> > can't ship), I don't yet fully understand the urgency on the remaining
> > parts, except that it isn't how you wish to package Samba.  Either way,
> > I think it needs to be separated and detailed distinctly to the MIT krb5
> > issue.  
> 
> They are 2 different issues in part, but for us they are part of the
> same work @ RH so we do them at the same time given we have to go over
> all this code anyways.
> 
> > On HAVE_KRB5, perhaps it isn't clear, but the only purpose of HAVE_KRB5
> > in header files is to allow the autoconf build to continue to function
> > without kerberos headers on the system.  
> 
> We have a request to be able to build the file server w/o krb support I
> think from Volker. This should keep being the case in the waf build of
> the server too, as I hope we will ditch the autoconf build at some
> point. Supporting both autoconf and waf build at the same time is too
> resource expensive. I even gave an initial crack at autogenerating
> Makefile.in from WAF, had no time to complete it but I think it is quite
> doable.

On this problem you have my full agreement.  Supporting two build
systems is just too resource expensive.  

As to solutions, we already have a install_with_python.sh, and agreed to
ship a 'with python' tarball if required.  (And I think your skills and
the team's long-term maintenance resources are much better spent on the
other challenges in this mail than auto-generating a second build
system)

> > On the role of private libraries - private libraries are most often
> > created so as to ensure that code is not linked into two subsystems that
> > will then be linked into the same binary or library (causing duplicate
> > symbols).  I do agree that this does create a lot of private libraries,
> > but I do not see a good alternate solution at this point. 
> 
> The solution is to fix interfaces that unnecessarily create circular
> dependencies. And finally merging all the many libraries in a few
> clearly bounded libraries that implement what we need in a reasonable
> set of discrete components that make sense on their own.
> 
> > In terms of the dependency chain, perhaps this would be a good meaning
> > for deps and public_deps?  That is, declare in public_deps the things
> > that header files published for this subsystem need, and only propogate
> > it for -I, rather than link-time?
> 
> It goes beyond mere header status. It really is about fixing interfaces
> and circular depdnencies with reasonable abstractions.
> 
> To be clear we are not working on fixing all the dependency issues at
> this stage. We are concentrating on fixing only those that are relevant
> for client libraries were those dependencies would end up dragging in
> KDC bits.

OK, that seems more reasonable.  This is why I asked if you could
contain the discussion of issues around MIT kerberos to those that are
essential in that way.  

> > On the final point, that is that we use the roken DNS library:  I can
> > understand why it might be valuable to change, so that we can use the
> > internal DNS server in make test, but why is this a MIT kerberos issue?
> 
> Because it is a build issue, but it's not a big deal I have already a
> set of prelimiary patches that use code already available in samba3 and
> samba4 to replace use of roken dns functions. We never really needed to
> use them and we shouldn't as they are no better than directly calling
> res_search and res_query as that's what they do underneath.
> 
> > Are you under a restriction that prohibits the use of any
> > Heimdal-derived code, even when it isn't in the krb5 namespace?  (The
> > reason I ask is that I would like the option to be able to move to
> > generated ASN.1 code, and I would prefer not to make a rule that would
> > prohibit the use of that compiler). 
> 
> The problem is that you have to be able to clearly build them w/o ending
> up depending on the whole heimdal code base, or you drag in krb5 from
> heimdal again.

I'm quite certain we can depend on just the roken or asn1 compiler parts
if we need to. 

> As for ASN.1 I would like to know where do you need to use heimdal asn1
> generator, and if you have looked at alternatives that will not bind us
> to Heimdal.

No, I've not looked into alternatives, or made a serious proposal at
this point.  I just want to understand if there is a reason that
'binding us to Heimdal' for a component that does not conflict with MIT
Kerberos would need to be forbidden by policy, any more than a choice of
ASN.1 compiler would bind to us to that compiler. 

> > I hope this helps you understand my concerns,
> 
> As well as I hope you understand our needs.

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org