Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 723352 - sys-libs/pam-1.3.1-r2 uses setcap without depending on libcap
Summary: sys-libs/pam-1.3.1-r2 uses setcap without depending on libcap
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mikle Kolyada
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-16 10:43 UTC by Simon
Modified: 2020-05-27 13:12 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Simon 2020-05-16 10:43:48 UTC
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
Comment 1 Matt Turner gentoo-dev 2020-05-17 17:56:06 UTC
It actually does depend on libcap via fcaps.eclass.

I've been battling this for Gentoo's release engineering builds.
Comment 2 Larry the Git Cow gentoo-dev 2020-05-17 18:12:30 UTC
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(-)
Comment 3 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-05-25 09:14:30 UTC
I was unable to reproduce this.
Comment 4 dwfreed 2020-05-25 20:59:02 UTC
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.
Comment 5 Zac Medico gentoo-dev 2020-05-25 21:28:31 UTC
(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
Comment 6 Zac Medico gentoo-dev 2020-05-25 21:55:17 UTC
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
Comment 7 Simon 2020-05-25 22:18:34 UTC
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?
Comment 8 Zac Medico gentoo-dev 2020-05-25 22:32:43 UTC
(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.
Comment 9 Simon 2020-05-26 18:13:20 UTC
(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?
Comment 10 Mikle Kolyada archtester Gentoo Infrastructure gentoo-dev Security 2020-05-27 13:12:22 UTC
Looks like we have nothing to do here as bug 723278 describes the problem better.