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 <go...@pld-linux.org> _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en