These were reported by Carlos Rodriguez-Fernandez with respect
to some analysis performed on the Fedora libcap-2.71 package.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
On relatively new architectures (for example ARM64, RISC-V, and
LoongArch), the kernel does not have a getdents syscall. Use getdents64
instead to fix the build on them.
The getdents64 syscall was added in Linux 2.4 and I don't think we
should still support older kernels today.
Signed-off-by: Xi Ruoyao <xry111@xry111.site>
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>
How this is relevant to the PSX code (since its 2.72 refactor) is the
subject of:
https://bugzilla.kernel.org/show_bug.cgi?id=219478
Since we've decided to not fully support earlier versions of Go by
working around this bug any longer, modify the test to not test for
this bug.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This addresses the following bug:
https://bugzilla.kernel.org/show_bug.cgi?id=219456
insofar as it eliminates the need for -wrap=pthread_create
linkage. Mostly, code that uses -lpsx functions can simply
link with -lpsx now. However, for legacy reasons the library
still works when linked wrapped or with the new content of
the libpsx.pc file:
-Wl,--no-as-needed -Wl,--whole-archive -lpsx -Wl,--no-whole-archive -Wl,--as-needed -lpthread
These last options are required for getting -lcap to act at a
consistent process level and not a thread level.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The refactoring of libpsx to operate at a LWP level and not
the pthread level has caused an old Go issue to reappear.
Details:
https://bugzilla.kernel.org/show_bug.cgi?id=219478
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Trying to find a path for not needing linker wrapping.
This feels like a step in the right direction, but doesn't
allow removal of the -wrap linkage yet.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The refactored libpsx code does not operate at the pthread
abstraction. We still need the --wrap linkage to force
libpsx to be linked into the binary if the binary makes
no explicit calls to libpsx functions. But we should no
longer need it in cases where the code calls psx_syscall[36]().
This is a step towards addressing:
https://bugzilla.kernel.org/show_bug.cgi?id=219456
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
These may seem excessive, but:
- 3 are for Go module version naming automation
- 1 is for kernel.org automation purposes
- 1 is for legacy consistency tagging
- 1 moving forward "official" tagging (packagers can use this one)
I've back-signed all of the libcap-2.xy releases with the "official" key:
$ gpg --fingerprint 0D23D34C577B08C4082CFD76430C5CFF993116B1
pub ed25519 2024-10-26 [SC]
0D23 D34C 577B 08C4 082C FD76 430C 5CFF 9931 16B1
uid [ultimate] Andrew G. Morgan (2024+ libcap signing key) <morgan@kernel.org>
sub cv25519 2024-10-26 [E]
Since the legacy tag uses a no longer considered secure technology,
I'll likely stop using it around libcap-2.75 when the new key has
gained more history and trust.
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>
Starting with libcap-2.71 the following key is considered
the load bearing one on tags sig-libcap-2.xy:
0D23D34C577B08C4082CFD76430C5CFF993116B1
We'll back tag all of the libcap-2.* releases with the
corresponding signed tag.
Further, starting with libcap-2.72, we'll transition all of
the Go package tags (*v1.2.xy) to be signed with this key.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
This demonstrates libpsx-2.72+ is now compatibile with the
std::thread variety of C++ threading under Linux.
This completes support for:
https://bugzilla.kernel.org/show_bug.cgi?id=218607
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>
Pass the flags as they might be needed by $(CC) to properly compile or
link an executable (e.g. --sysroot).
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
Limit the conditions where we raise CAP_SETPCAP to set an IAB value.
There are some situations where that capability is needed, but they
are by no means a requirement for all IAB value setting.
Credit for discovering this goes to Christopher Head and reporting
it in:
https://bugzilla.kernel.org/show_bug.cgi?id=219169
Update the man pages to better reflect use of Amibient bit setting.
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
It looks like the Linux-PAM folk have deprecated this macro. Compiler optimization
is hard to account for: apparently this explicit deletion is no longer
guaranteed to work. This function was marked deprecated in v1.5.3 of Linux-PAM.
I've replaced its use with memset(). I'm not convinced that that will be honored
either, but remain hopeful and prefer to leave the code explicit in its intent
without a deprecation warning messing up the build log. Should some compiler
optimize it away and it leads to an exploit of some sort, it can be revealed as
a compilation bug.
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>
Other than the case of /dev/null, there is no situation in which pam_cap.so
should act on world writable config files.
There are legitimate local administration choices for the file being owned
by non-root users, and similarly writable by a group of trusted users. So,
we do not require any specific ownership for the file and do not check for
writable access based on owner of group membership.
Credit for finding this bug in pam_cap.so goes to X41 D-Sec GmbH
(https://x41-dsec.de/) who performed a security audit of the libcap
source code in April of 2023. The audit was sponsored by the Open
Source Technology Improvement Fund (https://ostif.org/).
Audit ref: LCAP-CR-23-101
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
The function pam_set_data() takes ownership of a memory pointer if
the call succeeds, but does not take that ownership if the function
fails. Previously, the failure caused no deferred capability setting and
a return code PAM_IGNORE. It continues to do that in this case, but no
longer leaks the allocated iab memory.
This bug was introduced with deferred IAB capability setting support in
libcap-2.58.
Credit for finding this bug in pam_cap.so goes to X41 D-Sec GmbH
(https://x41-dsec.de/) who performed a security audit of the libcap
source code in April of 2023. The audit was sponsored by the Open
Source Technology Improvement Fund (https://ostif.org/).
Audit ref: LCAP-CR-23-100
Signed-off-by: Andrew G. Morgan <morgan@kernel.org>
