sys-libs/pam-1.3.1-r2 uses setcap without depending on libcap. see this line of the ebuild https://github.com/gentoo/gentoo/blob/55234cf8ac62747c1d18775060bfff1cfe951c67/sys-libs/pam/pam-1.3.1-r2.ebuild#L112 This results in a failure to emerge sys-libs/pam-1.3.1-r2 on a clean amd64 stage3 * Messages for package sys-libs/pam-1.3.1-r2: * FAILED postinst: 1 * Some software with pre-loaded PAM libraries might experience * warnings or failures related to missing symbols and/or versions * after any update. While unfortunate this is a limit of the * implementation of PAM and the software, and it requires you to * restart the software manually after the update. * * You can get a list of such software running a command like * lsof / | egrep -i 'del.*libpam\.so' * * Alternatively, simply reboot your system. * Setting caps 'cap_dac_override=ep' on file '/sbin/unix_chkpwd' failed: * /var/tmp/portage/sys-libs/pam-1.3.1-r2/temp/environment: line 1064: setcap: command not found * ERROR: sys-libs/pam-1.3.1-r2::gentoo failed (postinst phase): * could not set caps * * Call stack: * ebuild.sh, line 125: Called pkg_postinst * environment, line 2161: Called fcaps 'cap_dac_override' 'sbin/unix_chkpwd' * environment, line 1076: Called die * The specific snippet of code: * die "could not set caps" * * If you need support, post the output of `emerge --info '=sys-libs/pam-1.3.1-r2::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/pam-1.3.1-r2::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/pam-1.3.1-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/pam-1.3.1-r2/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/pam-1.3.1-r2/homedir' * S: '/var/tmp/portage/sys-libs/pam-1.3.1-r2/work/pam-1.3.1' Reproducible: Always
It actually does depend on libcap via fcaps.eclass. I've been battling this for Gentoo's release engineering builds.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c80be5a22f00558e763c473e572f0c5c22c9870e commit c80be5a22f00558e763c473e572f0c5c22c9870e Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2020-05-17 18:07:55 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2020-05-17 18:11:05 +0000 sys-libs/libcap: move sys-libs/pam from RDEPEND to PDEPEND Fixes install order for binpkgs. Bug: https://bugs.gentoo.org/723278 Bug: https://bugs.gentoo.org/723352 Signed-off-by: Mike Gilbert <floppym@gentoo.org> sys-libs/libcap/libcap-2.26-r2.ebuild | 5 +++-- sys-libs/libcap/libcap-2.27.ebuild | 5 +++-- sys-libs/libcap/libcap-2.33.ebuild | 5 +++-- sys-libs/libcap/libcap-2.34.ebuild | 5 +++-- 4 files changed, 12 insertions(+), 8 deletions(-)
I was unable to reproduce this.
This can happen in a fresh stage3 because portage rebuilds PAM due to turning on the filecaps USE flag, which is turned off in the building of the stage3 (due to tar not handling filecaps sanely), which brings in libcap. libcap's PAM USE flag is on by default (from default/linux profile), so it DEPENDs on PAM as well. Portage will rebuild PAM before it builds libcap, because it decides that the existing PAM installation doesn't satisfy libcap's dependency. We've discussed within releng about this extensively, and determined that the simplest workaround is to put libcap in @system, so that it's already installed in stage3.
(In reply to dwfreed from comment #4) > This can happen in a fresh stage3 because portage rebuilds PAM due to > turning on the filecaps USE flag, which is turned off in the building of the > stage3 (due to tar not handling filecaps sanely), which brings in libcap. > libcap's PAM USE flag is on by default (from default/linux profile), so it > DEPENDs on PAM as well. Portage will rebuild PAM before it builds libcap, > because it decides that the existing PAM installation doesn't satisfy > libcap's dependency. For reports like this, I have to check to see whether portage is doing the right or wrong thing. I've tested with stage3-amd64-20200524T214503Z just now and it succeeded: > # emerge -V > Portage 2.3.99 (python 3.7.7-final-0, default/linux/amd64/17.1, gcc-9.3.0, glibc-2.30-r8, 5.4.15-0128-x86_64 x86_64) > # emerge -av1 pam > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [ebuild N ] sys-libs/libcap-2.26-r2::gentoo USE="pam (split-usr) -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB > [ebuild R ] sys-libs/pam-1.3.1-r2::gentoo USE="berkdb cracklib filecaps* pie (split-usr) -audit -debug -nis (-selinux) -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB > > Total: 2 packages (1 new, 1 reinstall), Size of downloads: 0 KiB > > Would you like to merge these packages? [Yes/No] y > >>> Verifying ebuild manifests > >>> Emerging (1 of 2) sys-libs/libcap-2.26-r2::gentoo > >>> Installing (1 of 2) sys-libs/libcap-2.26-r2::gentoo > >>> Emerging (2 of 2) sys-libs/pam-1.3.1-r2::gentoo > >>> Installing (2 of 2) sys-libs/pam-1.3.1-r2::gentoo > >>> Jobs: 2 of 2 complete Load avg: 0.91, 0.41, 0.19
Also, binary packages work for me in stage3-amd64-20200524T214503Z, thanks to the PDEPEND fix from comment #2: > # emerge -av1K pam > > These are the packages that would be merged, in order: > > Calculating dependencies... done! > [binary N ] sys-libs/libcap-2.26-r2::gentoo USE="pam (split-usr) -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB > [binary R ] sys-libs/pam-1.3.1-r2-2::gentoo USE="berkdb cracklib filecaps* pie (split-usr) -audit -debug -nis (-selinux) -static-libs" ABI_X86="(64) -32 (-x32)" 0 KiB > > Total: 2 packages (1 new, 1 reinstall, 2 binaries), Size of downloads: 0 KiB > > Would you like to merge these packages? [Yes/No] y > >>> Emerging binary (1 of 2) sys-libs/libcap-2.26-r2::gentoo > >>> Installing (1 of 2) sys-libs/libcap-2.26-r2::gentoo > >>> Emerging binary (2 of 2) sys-libs/pam-1.3.1-r2::gentoo > >>> Installing (2 of 2) sys-libs/pam-1.3.1-r2::gentoo > >>> Jobs: 2 of 2 complete Load avg: 0.27, 0.31, 0.25
Zac, I think you're right and that possibly Mike's commit has addressed the problem. My bugreport wasn't complete, sorry about that. I was using binary packages just like mentioned in https://bugs.gentoo.org/723278. I was able to reproduce it 30 minutes ago, but after rebuilding the binary packages (the relevant one probably being sys-libs/libcap-2.26-r2) I can no longer reproduce it. P.S. I do think there's still a bug in the pam ebuild in that it should only do the fcap call when the filecaps USE flag is enabled. Or is there a way the fcap call could succeed without libcap installed?
(In reply to Simon from comment #7) > P.S. I do think there's still a bug in the pam ebuild in that it should only > do the fcap call when the filecaps USE flag is enabled. Or is there a way > the fcap call could succeed without libcap installed? The fcap function is supposed to enable the setuid bit when the filecaps USE flag not enabled, and it should succeed when libcap is not installed.
(In reply to Zac Medico from comment #8) > (In reply to Simon from comment #7) > > P.S. I do think there's still a bug in the pam ebuild in that it should only > > do the fcap call when the filecaps USE flag is enabled. Or is there a way > > the fcap call could succeed without libcap installed? > > The fcap function is supposed to enable the setuid bit when the filecaps USE > flag not enabled, and it should succeed when libcap is not installed. Thanks for the info. You're right, fcaps.eclass only calls setcap when the filecaps USE flag is set. I think my issue was caused by the binary packages then which now seems to be fixed. @dwfreed: Do you want to keep this issue open until libcap is added to @system or should that be tracked under a new issue?
Looks like we have nothing to do here as bug 723278 describes the problem better.
