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

[simo]

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.

> 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 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.

> 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.
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.

> I hope this helps you understand my concerns,

As well as I hope you understand our needs.

Simo.

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