Date: Sat, 9 Sep 2023 09:23:32 -0700 From: John Baldwin <jhb@FreeBSD.org> To: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: 15/14 upgrades break old sudo, maybe bump PAM's shlib? Message-ID: <27c5905c-1917-2ad5-6171-9be40693105e@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
I upgraded my laptop from a late June current to current from yesterday today, and after installworld sudo stopped working (dies with a SIGBUS). After some debugging, the issue ended up being OpenSSL library version mismatches as sudo uses PAM and PAM is linked agianst OpenSSL 3, but sudo is linked against OpenSSL 1.1.1. Both shlibs get mapped into the the process and at some point sudo crosses the streams and the crash occurs inside OpenSSL 3's libcrypto. I realize that we do have a generate note about needing to update third party packages after an upgrade, but I tend to use sudo as part of my workflow for doing that sort of thing. I generally build all my own packages via poudriere and use sudo at various points in that process, but even if I were using FreeBSD.org packages I would be using sudo to try to run 'pkg upgrade'. su(8) in base works fine, so that's my workaround for now on my laptop, but I wonder if we want to make this particular bump on the upgrade path a little less bumpy? Either by being clear in our release notes that tools like sudo (and I suspect any other third-party su wrappers that also use PAM, xscreensaver's screen lock doesn't seem to be affected since it probably doesn't use OpenSSL directly thankfully) can break, or another route we could take would be to bump the DSO versions of things that depend on libcrypto/libssl in base. We did not do this latter approach for the OpenSSL 1.0.2 -> 1.1.1 upgrade FWIW. If we wanted to do the shlib bump approach, Enji had a good list from a while back (though Enji wanted to make them all private rather than bumping): - kerberos - libarchive - libbsnmp - libfetch - libgeli - libldns - libmp - libradius - libunbound From my research it seems that PAM (library and modules), gssapi libraries, and libzfs would also need to be on the list. libldns is already private as is libunbound, though bumping them might be safter anyway. There is on libgeli, instead there is geli_eli.so which has no version, but hopefully is not widely used in ports the same as PAM. Note also that if we did this, we would want to do it for 14.0 as 13.x -> 14 upgrades are affected in the same way. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?27c5905c-1917-2ad5-6171-9be40693105e>