Bug#986051: unblock: krb5/1.18.3-5
Control: tags 986051 confirmed moreinfo
Hi Sam,
On Sun, Mar 28, 2021 at 02:13:29PM -0400, Sam Hartman wrote:
> [ Reason ]
> In #985739 it was pointed out that internal symbols disappeared from libk5crypto.
> My bad; I noticed this, confirmed they were not externally visible, approved the symbols file change, but didn't think about the upgrade implications.
>
> What happens is that if the new libk5crypto3 is unpacked before the
> new libkrb5-3, the old libkrb5-3 breaks. In the bug, the user managed
> to get into a position where pam_krb5 was broken and logins didn't
> work.
I was able to reproduce this issue with the following steps:
I started from the debian-10-generic-amd64-20210208-542.qcow2 buster cloud
image, and made sure root was able to login on the console (by setting a
password). After this, installing libk5crypto3 and libpam-modules from
bullseye (and the dependencies pulled in by apt) triggers this issue. At that
point, root is no longer able to log in on the console (I was able to login
via ssh using a key). Installing libkrb5-3 from bullseye fixes the issue.
The issue can also be triggered by installing libpam-krb5 (from buster), and
only upgrading libk5crypto3 to bullseye.
> So, update the breaks, or add an equals binary:Version depends, no big, right?
>
> While I wasn't looking, krb5 has apparently become part of
> pseudo-essential.
> login->libpam-modules->libnsl->libtirpc3->libgssapi-krb5-2->libk5crypto3|libkrb5-3
> The only reason I even know that is because I've been tracking pam.
>
> Long term, we don't want that.
>
> As a result, it's probably the case in #985739 that pam_unix is broken as well as pam_krb5.
>
> I'm not really an expert on all the ways that dependency resolution
> gets complex for essential packages. I do know that dependencies for
> essential packages are supposed to be pre-depends. That's not
> currently the case for anything in krb5, or for libkeyutils,
> libcomerr-2, etc.
>
> So, we have a few options.
>
> 1) Add the breaks. Things are fairly stable in this part of the
> dependency graph; it was 2016 when libk5crypto last had an
> internally-incompatible break. That will probably work in practice.
>
> On #debian-devel, Adrian Bunk argues that it should be a versioned conflicts not a break
> because it's essential. I'm not sure--I think in most situations the
> fact that you cannot unpack the breaking package without deconfiguring
> the broken package means that apt will simply reorder things so that
> libk5crypto3 comes before libkrb5-3 and all happens to be well with
> the breaks.
I did some tests with modified binaries with either the breaks or the
conflicts. Both result in the same upgrade order.
Looking at policy 7.4, the argument for conflicts could be that this is a case
"that must prevent both packages from being unpacked at the same time, not
just configured".
https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
I don't know if there is any situation where apt/dpkg would unpack
libk5crypto3 before libkrb5-3 if the breaks is present, so I don't know if it
makes any difference in practice.
Note that it's possible to install only
libgssapi-krb5-2 libk5crypto3 libkrb5-3 libkrb5support0
from bullseye on a buster system, and have a working system (note that I
didn't test if kerberos is actually working in this case, as I don't have a
kerberos setup). This means that I'm fairly confident that apt will be able to
solve this issue without creating other breakage, by just upgrading these
packages first (which it does in my tests).
I would unblock an upload with either the breaks or the conflicts.
> 2) Do we also want to add the pre-depends to krb5. I'm nervous adding
> additional pre-depends this late in the process.
>
> 3) Do we want to add pre-depends to the entire dependency chain from
> libpam-modules to libkeyutils|libcom-err2? I think this is
> technically correct, but I am uncomfortable with it.
I agree that adding pre-depends at this point doesn't sound like something
that we should try.
> 4) Do we want to do enough surgery to pam to avoid krb5 being
> essential. With my pam hat on in January, I concluded it was too late
> in the process for me to feel comfortable adequately testing a (not
> yet developed) patch. That was before I realized how big of a deal it
> might be that krb5 had become essential.
> The solution basically involves making pam_unix dlopen its dependencies for nis rather than link-time dependencies. So, ugly games with c macros or wrappers trying to get some internally typed NIS APIs right.
> I definitely do not have time to develop the patch, although I could potentially make time to review and help test.
> I consider this risky for bullseye.
I agree here as well.
> I think my recommendation is go approve the breaks change, and hope that's good enough in practice.
OK.
Please remove the moreinfo tag from the unblock bug when the new version is in
unstable.
Thanks,
Ivo
Reply to: