Multi-year bug displaying the wrong filename when failing
to set a capability on a file.
Thanks to Nikolas for reporting this:
https://bugzilla.kernel.org/show_bug.cgi?id=220245
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
kill(2) is declared in signal.h, however previously this header was not
included. It happened to work on glibc, where sys/wait.h includes
signal.h, this is however not required behavior in the POSIX standard:
> Inclusion of the <sys/wait.h> header may also make visible all symbols
> from <signal.h> and <sys/resource.h>.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Address user report of confusing behavior by adding a check to setcap
for a "<space...>" capability not meaning "-r".
Another suggestion from
https://bugzilla.kernel.org/show_bug.cgi?id=217592
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This change introduces the setcap -f argument to allow setting
of nonsense capabilities on files. But the default is to fail
when attempting to set such invalid capabilities.
This commit addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217592
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
There were a few straggler API functions in libcap and libpsx.
Also some functions that should be hidden from references outside
the library.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
When run via sudo, compare-cap exits with some file capabilities
left on its binary file. This is a test binary, so that's not a
big problem, however, it does mean that a 2nd run of the program
is started with, potentially, a different initial state.
This commit fixes that exit condition and addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=217018
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>
* 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>
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>
The flag --quiet causes capsh to suppress its startup check that
the linked libcap has support for all of the named capabilities
of the hosting kernel.
The cap_launch() support is via "-+" and "=+" arguments. These use
cap_launch() to fork() before exec*()ing the corresponding command
but are otherwise equivalent to "--" and "==" respectively.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Up to this point, capsh hides some complexity concerning raising
the CAP_SETPCAP in order to raise inheritable and drop bounding
set values. This made it harder to explain some aspects of
inheritance, and I ran into that detail writing this:
https://sites.google.com/site/fullycapable/why-didnt-that-work#h.z7rwbcazhr4r
Refactored capsh.c to clean up some buggy code, and also fix some
documentation, including reference to the --strict argument.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Things like /proc/* files don't support capabilities on them and
if getcap looks at them it generates a lot of errors. Treat it as
equivalent to there being no capability on the file.
This addresses
https://bugzilla.kernel.org/show_bug.cgi?id=214317
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
As explained (thanks David Seifert) there are some LDFLAGS that
need to precede actual linked libraries. For example, -Wl,--as-needed.
Given this, I've tried it and it appears to work for the default
build cases as captured in 'make distcheck'.
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>
Further observations from Zoltan Fridrich's static analysis of libcap.
This commit also includes a fix for something I broke with the last
round of "fixing", and a test to make sure I don't make that mistake
again.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The combined options 'getpcaps --iab --verbose' will show everything
in detail (even the boring stuff).
Also used this exercise to test the libcap changes for iab comparisons.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The intention was to force --static linking in only one corner case,
so be more explicit about that one, and revert the build behavior
in the others.
Reason for doing this was feedback from Arnout Vandecappelle in:
https://bugzilla.kernel.org/show_bug.cgi?id=214023#c16
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This brings libcap back to parity with the Go 'cap' package. We
provide a CAP_IAB_DIFFERS(result, vector) macro to evaluate the result
of cap_iab_compare().
Extend the getpcaps arguments to include --iab. This causes the utility
to explore the IAB tuple for the specified process. When used, this
outputs a text representation in a similar format to that of the
'captree' (Go) utility.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Discussion of one such setup in this bug (reported by David Runge):
https://bugzilla.kernel.org/show_bug.cgi?id=214023
Work around the failure to run ./pam_cap.so in these cases with
some more Makefile magic, and adjust test building with these
flags so it works in DYNAMIC=yes|no and SHARED=yes|no cases.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This is equivalent to 'capsh --print|fgrep Current'. I've been using
that combination a lot in the write-ups on the libcap website
(https://sites.google.com/site/fullycapable/) and so it struck me
that capsh probably should support it natively.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
