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>
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 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>
We had somewhat inconsistent checks before, so this should cut
down on corner cases to worry about.
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 2.54 (*Set).Compare() was deprecated in favor of (*Set).Cf(),
so update the top level comment to reflect the preferred API.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Based on what I see on go.dev, there seems to be some preferred
comment style for deprecating a function. Use it to help spread
the word.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
We also add the cap.ProcRoot() API to let the user redirect to their
local /proc/ directory - in case anyone runs with an unusual setup
like that.
I've been studying the downstream package definitions and no one
it doesn't seem popular to build the Go packages. Indeed, Go folk
themselves prefer to install via modules anyway, so we're getting
with the program.
However, if folk want to build test the Go stuff as part of a package
build and run an install as well, we reward them with the 'captree'
binary.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Older APIs remain but are documented as deprecated. If we ever need
to release a golang version "2" version of the library, I'll drop
support for deprecated functions, but I have no intention of needing
to do that. In the mean time, the deprecated functions are wrappers
around the new functions.
New API: *Set and *IAB have .Cf() functions now. That return a
[IAB]Diff value. This value, if 0, means the compared pointers
match one another. Non-zero values can be interogated with the
([IAB]Diff).Has() functions.
Also, add an IABGetPID() function. Since the kernel provides no
syscall support for this, we have to resort to parsing the /proc/
files. Implemented mostly for parity with the syscall backed
GetPID() *Set returning API.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Slavi Marinov was asking about how a single webserver might use the
cap package to serve different content as a different user? So I
realized this detail wasn't obvious from the package documentation.
I also put together this example sketch:
https://play.golang.org/p/6Hr0XW3JP6a
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
We previously added a cap_iab_fill() etc, functions. Bring the
regular capability flag manipulation API into alignment by
adding libcap.cap_fill() and (*cap.Set).Fill().
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
A desire for this stabilization came out of a conversation with a
Google colleague, Mike Schilling.
This commit unifies the default libcap/cap (Go) behavior with libcap2
with respect to the binary output of cap.Export(). Previously,
libcap/cap.Export() could generate shorter binary values. [To restore
that behavior, set libcap/cap.MinExtFlagSize = 0.]
Looking to some point in the distant future, this also prepares libcap
to retain the same exported binary representation for capabilities
defineable today... That is, if the kernel were to extend the capability
flags to be 96 bits, but a capability of "cap_chown=ep" would not touch
any of the higher bits, an 'exported' capability in external format
should not need to change. (Setting libcap/cap.MinExtFlagSize = 0,
cap.Export() => 8 bytes for this capability set in external format.
However, libcap and libcap/cap now both default to 29 bytes. That is
libcap2 has the more significant legacy footprint.)
In all cases, libcap/cap and libcap2 were previously interoperable,
being able to import each others exported format. This remains true
[independent of the setting of libcap/cap.MinExtFlagSize].
Addresses this bug:
https://bugzilla.kernel.org/show_bug.cgi?id=213375
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Ever wondered something like which capability allows a process
to do privileged things with a tty? Try this:
capsh --suggest="tty"
cap_sys_tty_config (26) [/proc/self/status:CapXXX: 0x0000000004000000]
Allows a process to manipulate tty devices:
- configure tty devices
- perform vhangup() of a tty
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
I found this corner case privilege escalation in December 2020.
Now that it is fixed upstream and widely deployed, add a test
so we don't regress.
[If you find 'make sutotest' fails for you, you should upgrade
your kernel.]
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
A convenience feature, so you don't have to grep the
system header, and/or wade through a man page.
This addresses:
https://bugzilla.kernel.org/show_bug.cgi?id=212451
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
