Hi, On Wed, Feb 11, 2026 at 2:36 PM Russ Allbery <[email protected]> wrote:
> Andreas Hasenack <[email protected]> writes: > > On Tue, Jul 9, 2024 at 11:55 AM Russ Allbery <[email protected]> wrote: > > >> 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]. > > I would love to get the same change into Debian, although Sam has been the > active maintainer for some time now and I would defer to him. > We can most definitely propose these changes to debian. I sent a follow-up email after I noticed I missed making this important statement :) > > > 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 > > This sounds fine. It does mean that any files in that directory will > suddenly be processed when they weren't before, but that seems acceptable > (and indeed the whole point). > Will add a note about this scenario as well. > > > 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? > > The reason why the symlink case is interesting is that it's not safe to > modify the file if it's a symlink. (It very well may not be possible, > which is the most likely case if it's a symlink into AFS.) In the current > implementation, that means that this change just won't be applied, which > probably warrants some sort of loud warning. > Will add a note to NEWS about the symlink case as well. > > The other option would be to fail the upgrade of krb5-config if krb5.conf > is a symlink and thus stop supporting symlinks. I'm not sure if that would > break anyone's use case, but it would make the addition of the new > includedir more reliable. > I think failing the upgrade in this case would be harsh. But I don't yet fully understand these scenarios. It's been a while since I last used AFS ;) > > > 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? > > I think that's correct. > > Thanks
