Gentoo Archives: gentoo-dev

From: Alec Warner <antarus@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] kerberos, virtuals, rattling cages
Date: Mon, 25 Feb 2013 03:46:55
Message-Id: CAAr7Pr8vH_O4cSvqhhRs-m1tBjEr8ZANMvN6Y+U+MkdLTbTf2w@mail.gmail.com
In Reply to: Re: [gentoo-dev] kerberos, virtuals, rattling cages by Michael Mol
1 On Sun, Feb 24, 2013 at 7:17 PM, Michael Mol <mikemol@×××××.com> wrote:
2 > On 02/24/2013 09:48 PM, Alec Warner wrote:
3 >> On Sun, Feb 24, 2013 at 6:25 PM, Michael Mol <mikemol@×××××.com> wrote:
4 >>> (I really don't have time to actively participate on this list right
5 >>> now, but I believe that if I bring it up on b.g.o, I'll be directed
6 >>> here, so...)
7 >>>
8 >>> So I'm playing with net-fs/samba-4.0.3, AD and kerberos, and tried to
9 >>> enable kerberos system-wide on my server.
10 >>>
11 >>> No joy, as net-fs/nfs-utils has an explicit dependency on
12 >>> app-crypt/mit-krb5 (bug 231936) and net-fs/samba-4.0.3 depends on
13 >>> app-crypt/heimdal (for reasons noted in bug 195703, comment 25).
14 >>
15 >> I'm not familiar with anyone using Kerberos on Gentoo. I use it on
16 >> Ubuntu; but we do not use it with Samba (or at least, if we do, I am
17 >> not aware of it.)
18 >
19 > It's one of the core components of Active Directory, so anyone who puts
20 > a Gentoo machine on an AD domain will likely be using it. I'm playing
21 > around with Samba 4, which is supposed to have full support as a
22 > standalone AD controller. An AD controller is effectively a central box
23 > that manages and directs domain members to DNS (the host directory),
24 > LDAP (the user and authorization directory) and Kerberos (the
25 > authentication mechanism).
26
27 Don't misunderstand, I know what all these things are ;)
28
29 >
30 >>
31 >>>
32 >>> Questions:
33 >>>
34 >>> 1) If upstream isn't going to support mit-krb5, then use of samba-4.0.3
35 >>> and kerberos demands that things with explicit dependencies on mit-krb5
36 >>> either be fixed or not used at all.
37 >>
38 >> I'm fairly sure samba supports either kerberos implementation; is
39 >> there something that makes you think differently?
40 >
41 > The explicit dependency on app-crypt/heimdal in the ebuild, and comment
42 > 25 attached to b.g.o bug 195703. I've taken those at face value; I
43 > haven't followed up on them myself.
44 >
45 >>
46 >>>
47 >>> I'm the first activity on bug 231936 in two years...could someone please
48 >>> look into that one?
49 >>>
50 >>> 2) Is it possible to slot mit-krb5 and heimdal instead of pulling them
51 >>> through a virtual? My suspicion is "no", but I don't know enough about
52 >>> kerberos to say whether or not it would work, even as a hack.
53 >>>
54 >>
55 >> I'm not following you here. 'slot' means a very specific thing. You
56 >> are not actually suggesting we use SLOT, you simply want both versions
57 >> of the library to be installed in one ROOT?
58 >>
59 >> I would not advocate this approach. You should strive to have only one
60 >> kerberos implementation on a given machine.
61 >
62 > I'm really not certain, to be honest. It was my impression that slots
63 > allow for two different versions of a thing to be present on the same
64 > system, and that their different sonames on the system would lead to
65 > correct symbol resolution. (Although it would require that the soname
66 > being sought be adjusted in a dependent program to target the version
67 > required.)
68
69 mit-krb5 and heimdal are separate packages. They both provide krb
70 headers and kerb libraries. You could easily patch them to be on the
71 same system. The problem with doing so is that packages are expecting
72 only one set of kerberos headers and kerberos shared libraries.
73
74 We have the 'eselect' framework for switching between 'providers'
75 which we could use in this case (similar to say, the opengl libraries
76 your system might use.) It is not clear to me if switching providers
77 is at all safe in the kerberos instance, or if software built against
78 mit-krb5 would crash if you pointed the loader at some heimdal shared
79 objects.
80
81 >
82 > Even if it works, I acknowledge it's a nauseating hack for the circumstance.
83 >
84 >>
85 >>> I'm sure explicit dependencies on mit-krb5 and heimdal will continue to
86 >>> crop up, so (and forgive the nausea this might cause) it might help to
87 >>> slot mit and heimdal, and have virtual/krb5 depend on the presence of at
88 >>> least one.
89 >>>
90 >>
91 >> It is likely that explicit dependencies are wrong, and are just bugs.
92 >
93 > This is what I found in the ebuild for net-fs/nfs-utils:
94 >
95 > # kth-krb doesn't provide the right include
96 > # files, and nfs-utils doesn't build against heimdal either,
97 > # so don't depend on virtual/krb.
98 > # (04 Feb 2005 agriffis)
99 >
100 > Which I noted in a comment I attached to bug 231936 (relating to
101 > net-fs/nfs-util).
102 >
103 > In bug 195703 (relating to the samba-4 version bump), there's this:
104 >
105 > "Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on
106 > virtual/krb5 but instead directly on heimdal after the com_err.h problem
107 > is fixed." in comment 25, dated 2009-11-24 23:07:18 UTC.
108 >
109 > Directly responded to later by this:
110 >
111 > "Agreed." in comment 26, dated 2009-11-25 10:01:48 UTC
112 >
113 >
114 >
115
116 So nothing recent then ;p
117
118 I think just 'eras' is the only person in the kerberos herd at this
119 point. I only have a passing interest in it myself (and I'm not
120 looking to maintain it in Gentoo ;))
121
122 -A

Replies

Subject Author
Re: [gentoo-dev] kerberos, virtuals, rattling cages Michael Mol <mikemol@×××××.com>