As a workaround for the golang bug: 70630, specifically comment
70630#issuecomment-2513491664 provide an alias for the package.
Perhaps, at some point, that bug or the one it is duped into will
be fixed, and we can remove this workaround.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Still trying to coax some go.dev documentation into providing runnable
examples. Iterating with a single simple one.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Trying to coax some go.dev documentation into providing runnable
examples. Starting with a single simple one.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Discussion and explanation of what is up here is in:
https://bugzilla.kernel.org/show_bug.cgi?id=219169
This gets the Go cap package to parity with the recent changes to
libcap. This change will be live in cap/v1.2.71.
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>
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>
