This is a forward looking feature request (Gentoo does not currently ship with libcap-2.52 or later), but when it does (2.53 contains a libcap C API bugfix for example), I would like to request that the three *.so objects built are installed as executables. Today, these binaries are installed on Gentoo as non-executables, but readable by all. However, libcap-2.52 added support for directly running these shared libraries (they output text information, and in the pam_cap.so case even support the --help command line argument). This run-as-a-binary thing is a longstanding feature of libc.so.2 so there is precedent for shared libraries to be installed as executables. Indeed, on other distributions all *.so files are installed as executables, but have a tendency to segfault when run! Reproducible: Always Steps to Reproduce: 1. build libcap 2. install binaries 3. ls -l /lib/x86_64-linux-gnu/security/pam_cap.so Actual Results: -rw-r--r-- 1 root root 14176 Feb 6 2019 /lib/x86_64-linux-gnu/security/pam_cap.so Expected Results: [When built from libcap-2.52+ sources (2.53 recommended)] -rwxr-xr-x 1 root root 14176 Aug 11 2021 /lib/x86_64-linux-gnu/security/pam_cap.so $ /lib/x86_64-linux-gnu/security/pam_cap.so --help /lib/x86_64-linux-gnu/security/pam_cap.so (version libcap-2.53) is a PAM module to specify inheritable (IAB) capabilities via the libpam authentication abstraction. See the libcap License file for licensing information. Release notes and feature documentation for libcap and pam_cap.so can be found at: https://sites.google.com/site/fullycapable/ ./pam_cap/pam_cap.so supports the following module arguments: debug - verbose logging (ignored for now) config=<file> - override the default config with file keepcaps - workaround for apps that setuid without this autoauth - pam_cap.so to always succeed for the 'auth' phase default=<iab> - fallback IAB value if there is no '*' rule I'm creating this bug for when Gentoo upgrades to a more recent version of libcap. No action is needed before then.
Really appreciate you filing these bugs, thank you! We do have libcap-2.52, but not 2.53. I had a brief look last night but there's a patch [0] which needs rebasing (and ideally upstreaming!) for the build system first. [0] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/libcap/files/libcap-2.52-build-system-fixes.patch
Hard to tell what that patch actually does, other than disable the $(MAKE) -C tests $@ target. I'm not likely to accept it upstream as written. Other than that, it seems to replace IPATH with CPPFLAGS (there is no C++ in the whole distribution). It also seems to disable the CROSS_COMPILE support which was contributed by the emlix.com folk, and since I don't do any cross-compilation myself, I'm loathe to mess with that.
(In reply to Andrew G. Morgan from comment #2) > Hard to tell what that patch actually does, other than disable the > > $(MAKE) -C tests $@ > > target. I'm not likely to accept it upstream as written. > > Other than that, it seems to replace IPATH with CPPFLAGS (there is no C++ in > the whole distribution). It also seems to disable the CROSS_COMPILE support > which was contributed by the emlix.com folk, and since I don't do any > cross-compilation myself, I'm loathe to mess with that. Hi Andrew! great to see you caring about distros, it's rather rare to see upstream maintainers commenting on downstream bugzillas. Let's see whether we can upstream our patches to you, which would help our maintenance a lot! Here are a few points: 1. In most cases, you're hardcoding variables that makes them unnecessarily hard to override. For instance, AR := $(CROSS_COMPILE)ar means we can't just export AR in the environment and get that respected. Deleting this flag as we do makes no practically difference, because POSIX mandates that $(AR) evaluate to "ar" if it isn't specified. The $(CROSS_COMPILE) variable isn't helpful, because this isn't how anyone generally invokes cross-compilation (Gentoo or otherwise). Anyone doing cross compilation will specify CC and BUILD_CC and any other flags directly. 2. CPPFLAGS has nothing to do with C++. https://www.gnu.org/prep/standards/standards.html#Command-Variables says about CPPFLAGS: "Use CPPFLAGS in any compilation command that runs the preprocessor". Automake customarily uses CPPFLAGS for both C compilation and C++ compilation, Meson does this too. Why do we care about CPPFLAGS? Eventually, we want users to add -DNDEBUG to their CPPFLAGS, in order to remove most asserts and other debugging code. GNU considers CPPFLAGS a user variable that should be respected, hence our patch. 3. You shouldn't inject tests into the "all"/default target. On many platforms, single tests fail or some other specific circumstance prevents them from running. Automake doesn't run tests as part of the normal workflow, only when invoking them via "make check". If you always unconditionally invoke tests, and they fail for some reason, we can't complete installation. In cross-compilation settings, you generally can't run tests, which is why Automake doesn't add "check" to the "all"/default/install targets.
1. Clearly we're at odds on this part. 2. I'll take a look. 3. The 'all' rule only builds the test binaries: targets 'test' and 'sudotest' run them
(In reply to Andrew G. Morgan from comment #4) > 3. The 'all' rule only builds the test binaries: targets 'test' and > 'sudotest' run them I should've looked more closely. Automake's "check" target also builds the binaries. Think of a first generation Raspberry Pi or so: If you never invoke the tests, why build the binaries?
All .so files installed by our libcap package have the execute bit set already. > % ls -l /lib64/libcap.so.2.52 /lib64/libpsx.so.2.52 /lib64/security/pam_cap.so > -rwxr-xr-x 1 root root 39440 Aug 6 15:02 /lib64/libcap.so.2.52 > -rwxr-xr-x 1 root root 22720 Aug 6 15:02 /lib64/libpsx.so.2.52 > -rwxr-xr-x 1 root root 14456 Aug 6 15:02 /lib64/security/pam_cap.so Your example shows /lib/x86_64-linux-gnu, but we don't use that libdir on Gentoo. That looks like a Debian multi-arch path.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=377ecb31bade3f21c3b9648125eb00c3d23023b3 commit 377ecb31bade3f21c3b9648125eb00c3d23023b3 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-30 06:09:30 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-30 06:12:27 +0000 sys-libs/libcap: add 2.55 (unkeyworded) Only significant change here is revamping of our (previously rather large) build system patch. See the patch itself for more details. Much smaller version of patches from before thanks to upstream incorporating some of our changes. Unkeyworded for now just to give it a bit of time to settle, as the patch is a fair bit different to what it was before. Bug: https://bugs.gentoo.org/808807 (given this is where discussion occurred) Bug: https://bugzilla.kernel.org/show_bug.cgi?id=214085 Thanks-to: Andrew G. Morgan <morgan@kernel.org> (for reaching out & incorporating patches) Signed-off-by: Sam James <sam@gentoo.org> sys-libs/libcap/Manifest | 1 + .../files/libcap-2.55-build-system-fixes.patch | 119 +++++++++++++++++++++ sys-libs/libcap/libcap-2.55.ebuild | 85 +++++++++++++++ 3 files changed, 205 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0caf0b1124ce200e0cad5dc09ed141b45086717f commit 0caf0b1124ce200e0cad5dc09ed141b45086717f Author: Sam James <sam@gentoo.org> AuthorDate: 2021-08-30 21:30:49 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-08-30 21:35:35 +0000 sys-libs/libcap: update libcap-2.55 build system patch Mainly added in some missing LDFLAGS lines mainly (some are redundant but I'd rather be consistent, some were not). Bug: https://bugs.gentoo.org/808807 Signed-off-by: Sam James <sam@gentoo.org> .../files/libcap-2.55-build-system-fixes.patch | 172 ++++++++++++++++++--- .../{libcap-2.55.ebuild => libcap-2.55-r1.ebuild} | 0 2 files changed, 147 insertions(+), 25 deletions(-)
