Hello, reviving this old thread/bug. I tried reading through it all again.
On Tue, Jul 9, 2024 at 11:55 AM Russ Allbery <[email protected]> wrote: > Andreas Hasenack <[email protected]> writes: > > > I opened #1074775[1] to backport the heimdal patches that add include > > and includedir support, filed a couple of salsa PRs[2][3] with tests, > > and they were merged. Once there is a new upload of heimdal, we can > > consider making this change in kerberos-configs then. What do you think? > > I am in favor of making this change. Thank you very much for clearing the > blocker in Heimdal. This will, among other things, let me finally address > #756880[1]. > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=756880 > > We will go ahead with this change in Ubuntu. There is a PR up at [1]. > The change is not entirely trivial, however. Here are some things that > come to mind that we probably need a plan for how to handle: > > 1. For already-configured systems, should we add the include directive to > the existing krb5.conf file? Presumably the answer is yes, or the > migration is going to be rather difficult. Is there a correct place in > the krb5.conf file to add the include so that we get the correct > semantics for whether fragments override the main file or vice versa? > Are we going to break anyone's system by suddenly including the > fragments? We'll at least need a NEWS.Debian entry; maybe we also need > a debconf warning in some situations? > The PR has a NEWS entry, and deals with upgrades in the following way: - default installs ship with the includedir statement in krb5.conf - upgrades will get the includedir statement added if and only if it wasn't there before, commented out or not 2. With the current logic, it's not possible to guarantee that the include > directive has been added, since krb5-config by design doesn't touch a > krb5.conf file that's a symlink. That means it's possible to have the > latest version of everything installed and still not respect the > configuration fragments. Do we just live with this? I'm nervous about > moving critical configuration into a fragment when we can't guarantee > that the fragment is loaded. In the libpam-krb5 case, this can lead to > a security vulnerability. > I saw an answer to my question of "what is the scenario where /etc/krb5.conf is a symlink?". Let me paste it below for context, from Russ: > I suspect there's at least one site somewhere that makes /etc/krb5.conf a > symlink to some file in AFS, but I have no idea how common this sort of > thing is. Given that the local administrator can just replace the file > with one that doesn't have the includedir, I suppose that at some level > it's just another case of "the local administrator can break their own > system" and we mostly need to try to make people aware of it during > upgrades. So yeah, I agree it seems far fetched, and falls into the category "you made local changes". But on the other hand, why do we care if /etc/krb5.conf is a symlink or not? The includedir path is absolute, you mean that in the symlink scenario it could be wrong to have snippets in /etc/krb5.conf.d because we don't know where krb5.conf actually lives? > > 3. How do dependencies work? This change to krb5-config will require a > particular version of Heimdal, since earlier versions don't support > include (and will this break Kerberos entirely if the include is > present?). But krb5-config can't depend on any specific Kerberos > implementation, so I don't know how to represent this as a dependency. > And what dependency should a package that wants to use included > fragments have to ensure that those included fragments are loaded? > > The PR adds a Breaks for the versions of heimdal and mit kerberos that do not have includedir support. I'm unsure on which mit krb5 package to break, should it be the library libkrb5-3? Regarding the include ordering, heimdal has acked the bug and thinks it's worth fixing, but need a PR. We will treat this lack of ordering as a bug and process it, but won't block on it for this first change as we want to meet the 26.04 LTS feature freeze date which is next week. Many things were discussed in this bug, and we want to address them all as much as possible, but I think it's best to make some progress here at least. We will definitely miss something in these first iterations, but I think it's a move in the right direction. That being said, if we missed something catastrophic and obvious, or anything else really, please shout :) 1. https://code.launchpad.net/~bamf0/ubuntu/+source/kerberos-configs/+git/kerberos-configs/+merge/500077
