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. > 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). > 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. 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. > 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. -- Russ Allbery ([email protected]) <https://www.eyrie.org/~eagle/>
