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>
It took me a while to figure out why optimized C compilation seemed
to generate miscomputation of the Fibonacci number sequence. It appears
to be an unresolved issue with Go's internal linking which is discussed
here:
https://github.com/golang/go/issues/24321
For a compute kernel, it seems important to be able to accommodate
compiler optimization. This adds some refinement for the strategy
I'm exploring to address:
https://bugzilla.kernel.org/show_bug.cgi?id=216610
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This example was developed while investigating the issues discussed in:
https://bugzilla.kernel.org/show_bug.cgi?id=216610
At this time, it is not possible to build CGO_ENABLED=1 and include
the "psx" package without using its "cgo"-tagged build variant.
This example provides a worked example of doing the opposite: link a
CGO_ENABLED=0 binary with "psx", including some compiled C code.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Günther Noack reported some issues with automated dependency checking in
https://bugzilla.kernel.org/show_bug.cgi?id=216609
Perhaps these additional lines will help assist those things.
I did find a typo in pam_cap/execable.c so I've fixed that.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This started out as addressing this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=216585
But I then made crosslink.sh to figure out what I had missed, and
fixed those bits too.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
There is a longstanding WONT_FIX bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=12491
that has been causing capsh, when linked fully statically,
to segfault. So, for non-dynamic linking of capsh etc utilities
only link statically to libcap. This way, in tree builds can be
guaranteed to get to execute with in tree API changes. For
normal installations, DYNAMIC=yes works as before.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This exploit code requires a make variable to activate, but
is used in the companion article discussing this code to compare
and contrast setuid-root to file capable privilege. Tl;dr don't
use setuid-root for shared libraries in this way!
Follow along here:
https://sites.google.com/site/fullycapable/capable-shared-objects
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
* GNU grep 3.8 considers `egrep` and `fgrep` obsolescent and throws warnings:
./mkcapshdoc.sh > capshdoc.c.cf
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
fgrep: warning: fgrep is obsolescent; using /bin/grep -F
[...]
https://lists.gnu.org/archive/html/info-gnu/2022-09/msg00001.html
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
$ make
$ sudo go/captrace your-program
will attempt to explore what capabilities are needed to run
your program by observing when cap_capable() inside the kernel
is associated with your-program.
Other ways to invoke this are
$ sudo go/captrace --pid=<pid>
$ sudo go/captrace
The last of these traces everything running on a system.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Also down size the default capabilities needed by the 'sucap' su program.
This is aimed at addressing:
https://bugzilla.kernel.org/show_bug.cgi?id=215926
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>
Missed a vendor dependency for the ok.go file. More recent go releases
seem more picky about module or vendoring being used, and for the in-tree
builds we consistently use vendoring. So make sure the vendoring
directory set up has completed before trying to build ok.go.
The failure was reported by Tomasz Kłoczko.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This change adds support to capsh for the --noenv argument, which
will restore pre-libcap-2.65 behavior to capsh. The change we're
making here, however, is that capsh will now set the USER and HOME
environment variables when the command line contains --user=xxx.
The issue this addresses is described here:
https://bugzilla.kernel.org/show_bug.cgi?id=215926
This has been annoying me for long enough, and I want to clean up
the article:
https://sites.google.com/site/fullycapable/inheriting-privilege
to not pepper "--norc" in distracting places.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
go/captree was seeing lots of libcap_psx_test processes hanging around.
It turns out that the newly added _psx_cleanup() function was deadlocking
because inside a forked processes the psx_tracker.state was _PSX_INFORK
and never _PSX_IDLE.
This completes the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=215551
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>
It looks like go1.18 is going to default to CGO_ENABLED=0, so force
CGO_ENABLED=1 when building this cap-libcap comparison program.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=215603
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Kalen Hall reported that Valgrind detected a memory leak associated
with a multi-threaded program linked against libcap and libpsx.
https://bugzilla.kernel.org/show_bug.cgi?id=215551
I've been unable to validate this myself with valgrind (likely holding
it wrong), but did explore psx for allocated memory and via fprintf's
convinced myself that this change should pair all calloc()s with a
corresponding free().
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>
The CGO_ENABLED=0 failure mode is discussed in:
https://github.com/golang/go/issues/50113
At the present time, this only passes when the psx package is compiled
CGO_ENABLED=1. The problem being that a blocking read cannot be
interrupted by the CGO_ENABLED=0 build of package "psx". It does not
deadlock when compiled CGO_ENABLED=1 because the psx signal wakes the
reading thread up back into user space.
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>
When a syscall that yields different return values is called from
the Go psx.Syscall*() API, we want to mirror the behavior of the
native golang runtime.AllThreadsSyscall() function.
The previous inconsistency was pointed out by Lorenz Bauer in:
https://bugzilla.kernel.org/show_bug.cgi?id=215283#c8
[I decided to defer this change until 2.63, and not include this
in the bug-fix for 215283, on the grounds it is a slight
incompatibility in runtime behavior, and wanted to give folk an
opportunity to plan for it. This new behavior enforcement will
crash an unprepared go program.]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This should complete the fix for:
https://bugzilla.kernel.org/show_bug.cgi?id=215283
Simplify the code, and add a test that the kernel has confirmed that
the thread is no longer running.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Lorenz Bauer found a race condition in the cap.Launcher teardown
process and reported it here:
https://bugzilla.kernel.org/show_bug.cgi?id=215283
This seems to significantly improve the situation. I'm going to
study the test case some more, but this is definitely part of the
solution.
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>
