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

[Alexander Bokovoy]

On Wed, May 9, 2012 at 12:54 AM, Andrew Bartlett <abartlet at samba.org> wrote:
>> > 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?
At that time I asked anyone (and you) to point me how to achieve the
same with Heimdal. Unfortunately, no answer came back. I understand
there are unsupported APIs on both Heimdal and MIT Kerberos sides but
the point of my work was to improve security of LDAP access and
confinement that would allow to get stricter rules on privileged
operations without resorting to root-level all-or-nothing techniques.

>> 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.
libroken is a libreplace for Heimdal, it is a tool to get around
broken system implementations for certain functions. We already have
libreplace for that purpose in Samba itself and I'd recommend to add
functionality to it if that is really needed rather than pulling more
wrappers into general samba code from a separate library. However, in
particular case of DNS resolvers this isn't really needed -- we have
lib/addns and can use that for a common DNS client code already. See
Simo's tree for a first cut of that work.

ASN1 compiler -- I hope the functionality we need from it does not go
above commonly supported set of functionality so there is no problem
in using any of standalone available ones, for example,
http://lionet.info/asn1c/compiler.html. Said that, from an integrated
distribution perspective using the one that is provided by the
platform in question would be beneficial, if possible.

>> 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.
As long as it possible to configure it separately from the rest of
Heimdal code, that is fine. Same goes for any embedded/integrated
library/application I'd guess. It is not really a crusade against
Heimdal but rather an effort to get choice where it is needed in real
life integration work.

-- 
/ Alexander Bokovoy