Re: [gentoo-dev] kerberos, virtuals, rattling cages

[Michael Mol]

On 02/24/2013 10:46 PM, Alec Warner wrote:
> On Sun, Feb 24, 2013 at 7:17 PM, Michael Mol <mikemol@×××××.com> wrote:
>> On 02/24/2013 09:48 PM, Alec Warner wrote:
>>> On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol <mikemol@×××××.com> wrote:
>>>> (I really don't have time to actively participate on this list right
>>>> now, but I believe that if I bring it up on b.g.o, I'll be directed
>>>> here, so...)
>>>>
>>>> So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to
>>>> enable kerberos system-wide on my server.
>>>>
>>>> No joy, as net-fs/nfs-utils has an explicit dependency on
>>>> app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on
>>>> app-crypt/heimdal (for reasons noted in bug 195703, comment 25).
>>>
>>> I'm not familiar with anyone using Kerberos on Gentoo. I use it on
>>> Ubuntu; but we do not use it with Samba (or at least, if we do, I am
>>> not aware of it.)
>>
>> It's one of the core components of Active Directory, so anyone who puts
>> a Gentoo machine on an AD domain will likely be using it. I'm playing
>> around with Samba 4, which is supposed to have full support as a
>> standalone AD controller. An AD controller is effectively a central box
>> that manages and directs domain members to DNS (the host directory),
>> LDAP (the user and authorization directory) and Kerberos (the
>> authentication mechanism).
>
> Don't misunderstand, I know what all these things are ;)
>
>>
>>>
>>>>
>>>> Questions:
>>>>
>>>> 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3
>>>> and kerberos demands that things with explicit dependencies on mit-krb5
>>>> either be fixed or not used at all.
>>>
>>> I'm fairly sure samba supports either kerberos implementation; is
>>> there something that makes you think differently?
>>
>> The explicit dependency on app-crypt/heimdal in the ebuild, and comment
>> 25 attached to b.g.o bug 195703. I've taken those at face value; I
>> haven't followed up on them myself.
>>
>>>
>>>>
>>>> I'm the first activity on bug 231936 in two years...could someone please
>>>> look into that one?
>>>>
>>>> 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them
>>>> through a virtual? My suspicion is "no", but I don't know enough about
>>>> kerberos to say whether or not it would work, even as a hack.
>>>>
>>>
>>> I'm not following you here. 'slot' means a very specific thing. You
>>> are not actually suggesting we use SLOT, you simply want both versions
>>> of the library to be installed in one ROOT?
>>>
>>> I would not advocate this approach. You should strive to have only one
>>> kerberos implementation on a given machine.
>>
>> I'm really not certain, to be honest. It was my impression that slots
>> allow for two different versions of a thing to be present on the same
>> system, and that their different sonames on the system would lead to
>> correct symbol resolution. (Although it would require that the soname
>> being sought be adjusted in a dependent program to target the version
>> required.)
>
> mit-krb5 and heimdal are separate packages. They both provide krb
> headers and kerb libraries. You could easily patch them to be on the
> same system. The problem with doing so is that packages are expecting
> only one set of kerberos headers and kerberos shared libraries.
>
> We have the 'eselect' framework for switching between 'providers'
> which we could use in this case (similar to say, the opengl libraries
> your system might use.) It is not clear to me if switching providers
> is at all safe in the kerberos instance, or if software built against
> mit-krb5 would crash if you pointed the loader at some heimdal shared
> objects.

Don't misunderstand, I know about eselect. ;)

And, yeah, I don't know if thunking/shimming/redirecting is safe in the
kerberos context. If it was, there should never have been any question
of compatibility.

>
>>
>> Even if it works, I acknowledge it's a nauseating hack for the circumstance.
>>
>>>
>>>> I'm sure explicit dependencies on mit-krb5 and heimdal will continue to
>>>> crop up, so (and forgive the nausea this might cause) it might help to
>>>> slot mit and heimdal, and have virtual/krb5 depend on the presence of at
>>>> least one.
>>>>
>>>
>>> It is likely that explicit dependencies are wrong, and are just bugs.
>>
>> This is what I found in the ebuild for net-fs/nfs-utils:
>>
>> # kth-krb doesn't provide the right include
>> # files, and nfs-utils doesn't build against heimdal either,
>> # so don't depend on virtual/krb.
>> # (04 Feb 2005 agriffis)
>>
>> Which I noted in a comment I attached to bug 231936 (relating to
>> net-fs/nfs-util).
>>
>> In bug 195703 (relating to the samba-4 version bump), there's this:
>>
>> "Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on
>> virtual/krb5 but instead directly on heimdal after the com_err.h problem
>> is fixed." in comment 25, dated 2009-11-24 23:07:18 UTC.
>>
>> Directly responded to later by this:
>>
>> "Agreed." in comment 26, dated 2009-11-25 10:01:48 UTC
>>
>>
>>
>
> So nothing recent then ;p

Which is exactly why I bring it up; the net-fs/nfs-utils bug is stale,
and the reference in the samba package is ancient. (Things directly
partaining to samba-4 get bounced into that bug, which really means a
stale comment is roughly the same as a stale bug...)

>
> I think just 'eras' is the only person in the kerberos herd at this
> point. I only have a passing interest in it myself (and I'm not
> looking to maintain it in Gentoo ;))

Yeah, I know, "if you want it fixed in Gentoo, fix it yourself." I would
if I had time. I may have time some day, but I wouldn't bet in that
direction. But it'd have been foolish not to at least try to shake the
dust off the issue. Apologies if I triggered any allergies... :)