Heimdal Bugs re update-alternatives

[Brian May]

Hello,

Can I please have some thoughts on #1070031?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070031

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

I am thinking they do very different things but maybe not. i.e. one
updates files for Heimdal KDC, the other updates files for MIT KDC.

But we don't what these packages to conflict either. What is the best
solution?

Also what can I do about #1095296?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095296

Seems that Heimdal tools are implemented as symlinks that point to
"/usr/bin/heimtools" and then use the program name to decide what to
do. Argh.

Please CC responses to me, thanks

[Gabor Gombas]

Hi,

Post by Brian May
Can I please have some thoughts on #1070031?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070031

Hmm, how is that possible? At a quick glance, heimdal-kdc Depends: on
heimdal-clients, and krb5-user Conflicts: with heimdal-clients. Oh I
see, this latter Conflicts: became versioned. Which is generally good,
except...

Post by Brian May
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.

Post by Brian May
I am thinking they do very different things but maybe not. i.e. one
updates files for Heimdal KDC, the other updates files for MIT KDC.
But we don't what these packages to conflict either. What is the best
solution?

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 have doubts if a MIT KDC would work with Heimdal's "kadmin -l"...

Post by Brian May
Also what can I do about #1095296?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095296
Seems that Heimdal tools are implemented as symlinks that point to
"/usr/bin/heimtools" and then use the program name to decide what to
do. Argh.

This one is nothing special - some commands behaving differently based
on argv[0] is a traditional Unix thing. "(exec -a klist klist.heimdal)"
should work.

Regards,
Gabor

[Russ Allbery]

Post by Gabor Gombas

Post by Brian May
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.

Post by Gabor Gombas
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.

[Gabor Gombas]

Post by Russ Allbery
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.

Yes, on clients that's fine, and it should work (with all the caveats
you mentioned). But the bug is about KDC packaging scripts failing if
kadmin from the other implementation is installed.

Post by Russ Allbery
I don't think anyone wants to mix implementations on the KDC itself.

Exactly - that's why making the KDC package Conflicts: with the other
implementation would be a quick fix. There aren't many KDC
implementations, and I think Shishi does not use kadmin (I'm not sure, I
never used it), so maintaining such Conflicts: does not sound like a
big burden.

Regards,
Gabor

[Brian May]

Post by Gabor Gombas
Exactly - that's why making the KDC package Conflicts: with the other
implementation would be a quick fix. There aren't many KDC
implementations, and I think Shishi does not use kadmin (I'm not sure, I
never used it), so maintaining such Conflicts: does not sound like a
big burden.

I have mixed feelings here.

On one hand, changing heimdal-kdc to use kadmin.heimdal instead of
kadmin would be easy. In fact, maybe I should do that anyway.

But having a kadmin around I think is confusing. It could point to MIT
or Heimdal and may very well do the unexpected thing. i.e. you might be
running a script that expects to update the MIT KDC, but it tries to
update the Heimdal KDC instead.

One option would be to have the two kdc conflict. The kadmin would only
ever point to one implementation.

Another option would perhaps be to delete the kadmin update-alternative
entirely, and just have the kadmin.heimdal. There is no conflict, and if
forces you to be explicity to request what you want. What do people
think of this solution?

[Brian May]

Post by Gabor Gombas
This one is nothing special - some commands behaving differently based
on argv[0] is a traditional Unix thing. "(exec -a klist klist.heimdal)"
should work.

Sorry, not 100% sure what you are trying to say here.

Are you suggesting that
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1095296 should be
treated as not a bug, and that the person invoking klist.heimdal needs
to modify the way they do it?