The road to add support for MIT Kerberos to be able to release Samba 4.0
abartlet at samba.org
Tue May 8 15:54:33 MDT 2012
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:
> This is what raised the urgency from we should do it, to we *have to* do
I thought that
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
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
> > 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.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
More information about the samba-technical