This addresses the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=219456
insofar as it eliminates the need for -wrap=pthread_create
linkage. Mostly, code that uses -lpsx functions can simply
link with -lpsx now. However, for legacy reasons the library
still works when linked wrapped or with the new content of
the libpsx.pc file:
-Wl,--no-as-needed -Wl,--whole-archive -lpsx -Wl,--no-whole-archive -Wl,--as-needed -lpthread
These last options are required for getting -lcap to act at a
consistent process level and not a thread level.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Trying to find a path for not needing linker wrapping.
This feels like a step in the right direction, but doesn't
allow removal of the -wrap linkage yet.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The refactored libpsx code does not operate at the pthread
abstraction. We still need the --wrap linkage to force
libpsx to be linked into the binary if the binary makes
no explicit calls to libpsx functions. But we should no
longer need it in cases where the code calls psx_syscall[36]().
This is a step towards addressing:
https://bugzilla.kernel.org/show_bug.cgi?id=219456
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Pass the flags as they might be needed by $(CC) to properly compile or
link an executable (e.g. --sysroot).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Limit the conditions where we raise CAP_SETPCAP to set an IAB value.
There are some situations where that capability is needed, but they
are by no means a requirement for all IAB value setting.
Credit for discovering this goes to Christopher Head and reporting
it in:
https://bugzilla.kernel.org/show_bug.cgi?id=219169
Update the man pages to better reflect use of Amibient bit setting.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Avoid something subtle with really long strings: 1073741823 should
be enough for anybody. This is an improved fix over something attempted
in libcap-2.55 to address some static analysis findings.
Reviewing the library, cap_proc_root() and cap_launcher_set_chroot()
are the only two calls where the library is potentially exposed to a
user controlled string input.
Credit for finding this bug in libcap goes to Richard Weinberger of
X41 D-Sec GmbH (https://x41-dsec.de/) who performed a security audit
of the libcap source code in April of 2023. The audit was sponsored
by the Open Source Technology Improvement Fund (https://ostif.org/).
Audit ref: LCAP-CR-23-02 (CVE-2023-2603)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Increase the enforcement of the documented libcap API by marking
internal library utility functions as "hidden". This also goes
for the .so executable entry points.
This addresses this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=217014
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Explicitly add (void) as argument lists for two function definitions:
cap_reset_ambient(void)
_libcap_initialize(void)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I'm not 100% sure this is needed, but I'm not yet convinced
'make distclean && make -j48 test' works reliably, but I find this
easier to reason about.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It looks like various distributions are fairly far behind HEAD for
their version of libcap. This way folk can work around a lack of
features in their code.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I've upgraded one of my systems to Fedora 35 and I found trimming
the headers in this way made the three compilations of libcap, used
by `make distcheck`, work with standard Fedora 35 compiler packages.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Since libcap does some error testing with a pre-main() constructor,
reset errno to zero as that constructor returns.
Problem reported by Yang Xu.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
David Seifert at Gentoo made a request to not require perl for
the libcap build since their distribution wants to build it prior
to building perl and so requiring it requires they maintain some
extra patches.
We previously introduced the need for perl in response to some
apparent incompatibilities between various versions of sed:
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=9494a1fab59ac0b6e4f0bfc536fa482c6d6490b6
However, it has been 13 years since that time so we're optimistic
those problems are no longer present for anyone and we've also
added a make variable abstraction in case some builder wants to
override their system default 'sed' as make BUILD_SED=... etc.
We've also done something similar with make uses of grep, egrep
and fgrep.
Finally, for make variable naming consistency, we've replaced use
of BUILD_GPERF with USE_GPERF. Since folk may be using BUILD_GPERF
in their package building scripts, we error out if it is set.
The expectation is that people will update their package defs.
(Eventually, we plan to reuse BUILD_GPERF as an alias for 'gperf'.)
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The previous commit crossed the beams on libpsx.so and libcap.so
executable build. This commit decouples them.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Mostly cause we can, but this gives a little more diagnostic
value to the libcap.so executable mode of operation.
usage: libcap.so [--help|--usage|--summary]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Not sure where this will go, but libcap.so uses _libcap_initialize()
to set itself up at start up. So, run it when invoking libcap.so
directly as a binary.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
There seems to be a subtle difference between glibc and musl over
whether or not a runnable *.so needs to start out with its stack
aligned to 16 bytes or not. Since Linux ABIs for x86 (both 32 and
64 bit varieties) require 16 byte alignment, just force it on both
these architectures.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=215009
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This was reported by Sam James and debugged with respect to:
https://bugs.gentoo.org/show_bug.cgi?id=820071
Modern versions of glibc employ SSE instructions that require the
stack to be aligned to 16 bytes in order to execute movaps and
friends to stack stored memory. The ABI for x86_64 requires this
alignment so we'd not seen this issue before being cc:d into the
bug.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Modify the cap_launch() behavior when chroot is set. Now, the
launcher code will force the post chroot() environment to
chdir("/").
Modify the API for many of the cap_launch_*() functions that
previously were void, to returning int (0=OK, -1=see errno).
I'm confident that this should be code backwardly compatible,
since the return values are new and prior code would have been
assuming success.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Embed mutex locked operation into the IAB API. The idea being that
while libcap operates on an IAB tuple, it cannot be operated on by
a thread running in parallel. This makes IAB access thread safe (but
not reentrant).
The only potential API behavioral change is that the IAB tuple
associated with a cap_launcher_t is now locked for the duration of
its association with that launcher. This prevents a race condition
with launching and another thread changing that IAB tuple.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
If two threads operate on the same cap_t value, ensure that the
operations occur atomically. (Not, however, reentrantly.)
Also added some sanity checking to cap_set_nsowner() and cap_get_nsowner().
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This API avoids a complex use case that requires substantially
more code outside of libcap.
Signed-off-by: Andrew G. Morgan <agm@google.com>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
In the vast majority of cases, code will not need to
override the "/proc" root directory, so treat NULL
as equivalent to "/proc".
Signed-off-by: Andrew G. Morgan <agm@google.com>
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This was a regresssion introduced in libcap-2.55. Fixed in libcap-2.59.
Added a cap_launch NULL test too. Comparing against NULL would cause a
SIGSEGV against these library revisions.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
* Respect user's CFLAGS/CPPFLAGS/LDFLAGS
* Respect $(MAKE)
* Remove CPPFLAGS from link rules
Note: for in-tree built test binaries, where we build --static,
we do not apply LDFLAGS: we want to limit external
dependencies in general; and users' LDFLAGS have a strong
tendency to conflict with --static for linking.
Work in collaboration with David Seifert (ie, he wrote most of it).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Noticed that we weren't applying the same amount of flag discipline
to local BUILD_* tool rules. Fixing that, I see we've been carrying
a source code issue in libcap/_makenames.c for a while. (FIXED).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I figured out that the key ingredient to reproducing this issue
was:
make COPTS="-D_FORTIFY_SOURCE=2 -O1 -g" clean test
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Not sure exactly what is causing the build server to fail (can't
reproduce yet), but add some extra padding to a calloc and also
some test debugging printf()s.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This is needed to locally configure libcap to find the pid data
if the proc filesystem is not mounted at "/proc" (rare). Currently
libcap only uses this info to implement cap_iab_get_pid().
This brings libcap back to parity with the Go "cap" package.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
