MIT kerberos vs heimdal

[Tomasz Pala]

On Fri, Feb 20, 2015 at 01:57:59 +0100, Tomasz Pala wrote:

> My point is - assuming I haven't forgot about anything (considering my last mail
> about versioned symbols) we could safely:
> 
> 1. compile samba against heimdal to have AD (as an exception!),
> 2. compile everything else against MIT,
> 2a. except the things that require KRB+SMB itself as a precaution (i.e.
>     the three packages mentioned earlier) (???)
> 
> 
> Rationale:
> 
> 1. there might be situations where:
> 
> binary	-> MIT KRB
> 	-> lib1	-> MIT KRB
> 	-> lib2 -> lib*smb* -> heimdal KRB
> 
> but this would be valid since all KRB symbols are versioned and there
> should be no path for any kerberos struct passing between lib1 and lib2
> (only between binary and lib1).
> 
> 2. every possible lib2 that uses both SMB _and_ KRB uses heimdal
> (currently gnome-vfs2-libs only).
> 
> 
> In other words: if we want samba-server using heimdal, it does NOT mean
> we need to build everything else using heimdal; client-server protocol
> effectively separates different API and ABI, symbol versioning separates
> ABI pulled in within single code executed.

It is even easier than I thought... According to
http://fedoraproject.org/wiki/Features/Samba4

"Samba 4 AD DC functionality relies heavily on Heimdal Kerberos
implementation. Samba 4 includes the embedded Heimdal, if your system
misses it, like we have in Fedora. When embedded Heimdal is in use, all
Samba 4 code is compiled against this Kerberos implementation, including
client side libraries and tools, and traditional file serving smbd
daemon we know as 'samba' package in Fedora."

we simply need to get rid of heimdal-devel and made samba use embedded
code. This all seems like another 'use system library no matter what'
PLD-like fuckup.

The next two paragraphs describe the problem I've tried to analyze:

"Heimdal and MIT Kerberos [...] have slightly different meaning to Kerberos
credential cache files format where Kerberos-aware applications store
their Kerberos keys. While this is not an issue for client-server
communication over a network (a Heimdal client does talk the same
Kerberos V protocol that MIT Kerberos server understands and vice
versa), interoperability of the client or server code using the same
credential cache files on the same system is much less supported for
advanced features like S4U2Proxy and S4U2Self.

It is generally not advisable to load two different API implementations
into the same address space either. When the rest of the system
libraries is compiled against MIT Kerberos, use of them within Samba 4
code brings in MIT Kerberos as well. This happens, for example, when
linking against OpenLDAP client libraries and using SASL
authentication."

...so what? There is no ABI conflict, one would have to deliberately mix them.

And just like I've thought, it's samba that needs to be fixed:

http://sambaxp.org/fileadmin/user_upload/SambaXP2014-DATA/wed/track2/Andreas_Schneider-TheroadtoMITKerberossupport.pdf

https://wiki.samba.org/index.php/MIT_Build

"In the merged build the build system attempts to hide Heimdal symbols
with use of various linker tricks. The merged build also uses
system-supplied libraries which are dynamically linked against the
system-provided Kerberos implementation, in our case MIT Kerberos. The
behavior of the system and the embedded Heimdal libraries is not always
consistent and breaks down in some cases.

[...] the MIT kerberos implementation stores information about it in the
ccache in the form of hints that Heimdal seem not to understand"

I don't know how did they manage to get the symbols bleeding (it was
written in 2012), but apparently there is a problem with shared
credential caches. To be honest, while using (embedded!) heimdal for AD
in samba makes sense, I don't really care for someone to have any
proxy-schmoxy-credentials-passing working at the cost of having ENTIRE
DISTRO compiled against obsoleted heimdal. PLD is not windows-centric to
sacrifice anything for AD.

For now I don't use any proxy-thingy, so it doesn't bother me if things
stay like they are, as long as heimdal-client won't break on MIT server.
However I do need MIT kerberos server working - and it's definitely not
'obsoleted' thing to put it into on FTP.

So the question is: how can I STB krb5 safely, i.e. not breaking your
heimdal-related stuff?

-- 
Tomasz Pala <gotar at pld-linux.org>