Re: MIT kerberos vs heimdal
On Sun, Feb 08, 2015 at 11:41:41 +0100, Jan Rękorajski wrote:
problem in having them both on ftp? Client libraries should be
compatible (i.e. heimdal client works with MIT server, that's the point
of having a 'protocol'). Incompatible parts are kadmin and probably
the rest of server stuff - heimdal package is divided accordingly
already, krb5 have libkadm5{clnt,srv}_mit and libgssapi_krb5 (suffixed),
the only conflicting library I see is libkrb5.so itself, but has
different SOVER.
You are mistaking protocol, API and ABI.
Protocol is the same, Heimdal has no problems at all taking to MIT and
vice versa. But if you try to run program linked with one in presence of
a library from other, things may go nasty.
I am aware of problems that might pop up when you mix multiple
ABI-incompatible libraries in single code executed. However I did a
quick research and fortunately the MIT krb5 library has all the symbols
versioned with _MIT suffix:
objdump -TC /usr/lib64/libkrb5.so.3.3 | grep -v krb5_3_MIT | grep -v UND
readelf -Ws /usr/lib64/libkrb5.so.3.3 | grep -v _MIT\$ | grep -v UND
while heimdal implementation uses it's own HEIMDAL_ prefix:
objdump -TC /lib/libkrb5.so.26.0.0 | grep -v HEIMDAL_KRB5_2.0 | grep -v UND
readelf -Ws /lib/libkrb5.so.26.0.0 | grep -v HEIMDAL_KRB5_2.0\$ | grep -v UND
So (correct me if I'm wrong) one could safely use binary linked with MIT
library and any other library that in turn is linked with heimdal one.
What would happen with your heimdal server if we changed heimdal-devel
to krb5-devel and rebuild everything? Shouldn't this keep working?
No. As I said, ABI is different, just look at 'heimdal' patches in repo,
MIT has some fancy functions Heimdal doesn't.
IMHO in this case you cannot say that ABI is different - in terms of ELF
these are completely different libraries, like libpng and libjpeg.
--
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
Re: MIT kerberos vs heimdal
On Sun, Feb 08, 2015 at 11:36:42 +0100, Jan Rękorajski wrote: But that's not the point, you missed the most important issue (system MIT makes samba4 useless): APIs and ABIs in Heimdal and MIT are different. Samba uses Heimdal to do AD DC kerberos. It does not build with MIT. Fedora distributes samba4 without Kerberos, makeing it effectively a samba3 PDC. The whole point of samba4 is it being full fledged MS AD DC. Is that explanation clear enough? OK, I see now. So let's do some logic: samba R: heimdal-libs-server fine; note nothing else requires this lib! openldap-overlay-smbk5pwd, python-samba, samba, samba-libs R: heimdal-libs-common fine; also, nothing else requires these! samba-libs are required by other samba subpackages (incl. libsmbclient) only - so all we need to crosscheck is libsmbclient vs heimdal-libs: poldek:/all-avail desc -B libsmbclient-4.1.14-1.x86_64 Package:libsmbclient-4.1.14-1.x86_64 Required(by): cifs-utils, fusesmb, gmerlin-avdecoder, gmplayer, gnome-control-center, gnome-vfs2-libs, gvfs-smb, kde4-kdebase-runtime, mencoder, mpd, mpd, mplayer, mpv, mpv-client-libs, perl-Filesys-SmbClient, [*samba*], vlc, xbmc, xine-input-smb Which one of those require heimdal-libs as well? cifs-utils, gnome-control-center, gnome-vfs2-libs These 3 might (should?) to be compiled using heimdal-libs. I've also checked what requires heimdal-devel, gnome-vfs2-devel, samba-devel and libsmbclient-devel and haven't seen any clashes. 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. and that's crucial now Samba is a real AD server. Just read README.dc from Fedora's samba package, it's so pathetic it still makes me laugh my ass off. That were the reasons we switched to Heimdal. Wasn't that the reason THEY have created FreeIPA for AD? Who are THEY? Fedora guys. As a solution for such heroic (or brain damaged) hackery required for setting up AD services you've mentioned they've ended up in FreeIPA. Isn't that better than our approach? Honestly I won't be capable of setting AD on PLD if I need to (well, mostly because I don't have any windows system to do step-by-step environment debugging) - MIT or heimdal, no difference, won't work and pld-doc doesn't help. -- 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
Re: MIT kerberos vs heimdal
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
Re: MIT kerberos vs heimdal
On Sat, 07 Feb 2015, Tomasz Pala wrote:
Whatever, let's assume some require heimdal, some MIT. What's the
problem in having them both on ftp? Client libraries should be
compatible (i.e. heimdal client works with MIT server, that's the point
of having a 'protocol'). Incompatible parts are kadmin and probably
the rest of server stuff - heimdal package is divided accordingly
already, krb5 have libkadm5{clnt,srv}_mit and libgssapi_krb5 (suffixed),
the only conflicting library I see is libkrb5.so itself, but has
different SOVER.
You are mistaking protocol, API and ABI.
Protocol is the same, Heimdal has no problems at all taking to MIT and
vice versa. But if you try to run program linked with one in presence of
a library from other, things may go nasty.
What would happen with your heimdal server if we changed heimdal-devel
to krb5-devel and rebuild everything? Shouldn't this keep working?
No. As I said, ABI is different, just look at 'heimdal' patches in repo,
MIT has some fancy functions Heimdal doesn't.
--
Jan Rękorajski| PLD/Linux
SysAdm | bagginsatpld-linux.org | http://www.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
Re: MIT kerberos vs heimdal
On Sat, 07 Feb 2015, Arkadiusz Miśkiewicz wrote: On Saturday 07 of February 2015, Tomasz Pala wrote: Anyone knows/remembers why did we choose heimdal over MIT? IPv6 support I guess. That was old reason, last time I checked MIT did not have LDAP and Samba support. Also no Samba flavor ever built with MIT, and that's crucial now Samba is a real AD server. Just read README.dc from Fedora's samba package, it's so pathetic it still makes me laugh my ass off. That were the reasons we switched to Heimdal. -- Jan Rękorajski| PLD/Linux SysAdm | bagginsatpld-linux.org | http://www.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
Re: MIT kerberos vs heimdal
Whatever, let's assume some require heimdal, some MIT. What's the
problem in having them both on ftp? Client libraries should be
compatible (i.e. heimdal client works with MIT server, that's the point
of having a 'protocol'). Incompatible parts are kadmin and probably
the rest of server stuff - heimdal package is divided accordingly
already, krb5 have libkadm5{clnt,srv}_mit and libgssapi_krb5 (suffixed),
the only conflicting library I see is libkrb5.so itself, but has
different SOVER.
What would happen with your heimdal server if we changed heimdal-devel
to krb5-devel and rebuild everything? Shouldn't this keep working?
--
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
