delta/libcap2.git/libcap/libcap.h, branch master

Recognize that NULL is an invalid cap_t and cap_iab_t.

2021-09-24T17:46:24+00:00

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

Eliminate an alignment issue found by clang.

2021-08-27T04:45:27+00:00

Clang helpfully noticed that libcap allocated things should be 64-bit
aligned on 64-bit platforms. Restructure the memory allocation to ensure
this.

Fixes:

   https://bugzilla.kernel.org/show_bug.cgi?id=214183

Signed-off-by: Andrew G. Morgan

Handle libcap allocation failures more explicitly and fix a memory leak.

2021-08-21T17:29:16+00:00

This started out as a refactoring of a patch provided by Samanta Navarro.
Reworked, I noticed a latent memory leak in cap_iab_get_proc(), so I've
fixed that too.

Also, migrated a compile failure check to a more useful cap_test for a
highly unlikely corner case (future proofing). While there, noticed
and fixed the binary search test and code (not sure what it was testing
before).

Signed-off-by: Andrew G. Morgan

Implement cap_launch.

2020-02-24T00:12:12+00:00

In threaded programs, it's a bit tricky to fork/execve a child with
capabilities different from the parent. Implement cap_launch and
friends to accomplish this.

https://bugzilla.kernel.org/show_bug.cgi?id=206195

Signed-off-by: Andrew G. Morgan

A convenient IAB abstraction for inherited capability vectors.

2020-02-24T00:00:02+00:00

Linux supports three flavors of inheritable capability vectors:

  - the I (inheritable set) of cap_t
  - the A (ambient) alternative to file capabilities
  - the B (bounding) vector.

The cap_iab_t collects these together into one object. I exactly equals
that of cap_t, A is what you would expect and B is "blocked" bits which
are ~cap_bound -- ie., 0 = nothing blocked.

Signed-off-by: Andrew G. Morgan

Refactor the way we do the psx linkage in libcap.

2020-01-03T22:00:22+00:00

Since we now have a serialized (linker trick) to initialize libcap
we can reliably compute the number of capabilities of the running
kernel in a race free way. Export the found number of capabilities
with the cap_max_bits() function. This is also what we now use in
both C and Go to define [all]=[eip]. In Go the equivalent function
is cap.MaxBits().

Signed-off-by: Andrew G. Morgan

Add support to libcap for overriding system call functions.

2019-12-07T07:06:47+00:00

Note, this override only supports the system calls that
libcap uses to change kernel state associated with the
current process. This is primarily intended to permit the
user to use libpsx to force all pthreads to mirror capability
and other security relevant state.

Use a weak function definition feature of libpsx share_psx_syscall()
to transparently arrange for libcap to so force itself to use the
psx_syscall() abstraction when linked against -lpsx. This has the
effect of using linker magic to make libcap transparently observe
POSIX semantics for security state setting operations. That is, when
linked as follows:

   gcc .... -lcap -lpsx -lpthread -Wl,-wrap,pthread_create

all pthreads maintain a common security state with respect to the
libcap API.

This also adds full capability setting support to the Go package
libcap/cap via a libcap/psx package which uses cgo+libpsx syscalls
that share capabilities over all pthreads including those of the
Go runtime.

Finally, if Go supports syscall.PosixSyscall() etc. then provide
a non-psx mechanism for libcap/cap to "just work" in all Go code.

Signed-off-by: Andrew G. Morgan

Fix undefined behavior by shifting integer (1u) instead of signed integer (1).

2019-04-21T16:17:04+00:00

This issue was found with a static analysis code quality linter highlighting
a 32-bit integer issue with some architectures.

Signed-off-by: Andrew G. Morgan 
Signed-off-by: Andrew G. Morgan

pull request -- libcap -- bugfix

2019-04-14T00:29:26+00:00

Hello, Mr. Andrew G. Morgan!

I've found a tiny bug in libcap public headers.

Unfortunately, I don't have an idea how to report this properly or make a
pull request on the kernel.org website (I don't have an account there). So,
I've just made a fork to my account on github.com and now sending a pull
request to you.

If these all should be done according to a different procedure, please,
feel free to ask me for that.

And here is my request for pull:

The following changes since commit 658325c875d36539fd66c6960433435706203759:
  Up the minor release number. (2018-09-15 14:54:14 -0700)
are available in the git repository at:
  https://github.com/xoiss/libcap.git master
for you to fetch changes up to 5497b45db823f86e13835b5e55cbe4091ef3bfe1:
  Fix mistakenly permuted parameter sets of capget and capset (2019-02-07
02:56:52 +0300)
----------------------------------------------------------------
Alexander A. Strelets (1):
      Fix mistakenly permuted parameter sets of capget and capset
 libcap/include/sys/capability.h | 4 ++--
 libcap/libcap.h                 | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

Signed-off-by: Andrew G. Morgan

cap_file: add new rootid argument

2018-09-09T21:22:50+00:00

Newer kernels support setting file capabilities in user namespaces. In
addition to directly setting file capabilites in a user namespaces they
can also be set in lieu of another user namespace by passing a uid down
to the kernel which will convert it to an appropriate kuid_t
representation.
This commit adds a new rootid argument to the internal struct
_cap_struct so that we can store the rootid when the kernel supports
VFS_CAP_REVISION_3 and returns a struct vfs_ns_cap_data.

Signed-off-by: Christian Brauner 
Reviewed-by: Serge Hallyn 
Signed-off-by: Andrew G. Morgan