Gabor Gombas <gomba...@gmail.com> writes:
> On Mon, Feb 10, 2025 at 08:59:47AM +1100, Brian May wrote:

>> Is it appropriate to use update-alternatives for kadmin that is supplied
>> with {Heimdal,MIT} Kerberos?

> ... in the real world, KDCs tend to be heavily locked down machines with
> not much else installed, due to their sensitivity. So while allowing
> random tools to be co-installed is generally a good thing, I don't think
> that would be a valid goal for a KDC. Making heimdal-kdc Conflicts: with
> krb5-user might not be the most elegant solution, but it would be fine
> for real-world KDC setups.

The kadmin client and the KDC package are very different things. The
kadmin client you can run from anywhere (and often wish to do so).

As someone who used to have to regularly deal with multi-implementation
Kerberos setups, I can confirm that there is a real need to be able to
install the Heimdal clients and the MIT clients (including kadmin) at the
same time. This is something that people have been asking for constantly
for over a decade and it would be great to accomplish it.

The problem from the Debian perspective is that the syntax of the kadmin
command lines is almost completely different, so normally that would not
qualify for alternatives because the tools are absolutely not drop-in
replacements for each other. This is to some extent true of the stuff in
krb5-clients and heimdal-clients as well (the flags to klist are very
different, for instance), and we have hand-waved this away and used
alternatives anyway because the benefits seem to outweigh the risks, but
it's a bit more stark with kadmin.

It's unfortunate that the commands have the same names in both Kerberos
distributions, although it's understandable from a user UI perspective.

I don't have a good solution. Either using alternatives or not using
alternatives runs some risk of breaking things. I think I'd lean towards
using alternatives for kadmin because I think anyone installing both
kadmin client packages probably knows what they're doing and can cope, but
technically it is a policy violation because the two commands do not
implement the same interface.

> I think this is a "I shot myself in the foot and it hurts" situation. If
> you don't want to add an explicit conflict, then you could add a note to
> README.Debian which says that mixing different Kerberos implementaions
> on a host which is meant to be a KDC is not necessarily a good idea.

I don't think anyone wants to mix implementations on the KDC itself.

-- 
Russ Allbery (r...@debian.org)              <https://www.eyrie.org/~eagle/>

Reply via email to