History log of /freebsd-current/tests/sys/capsicum/Makefile
Revision Date Author Comments
# 62d3f57c 28-Sep-2023 Mariusz Zaborski <oshogbo@FreeBSD.org>

capsicum: add tests for copy_file_range

Reviewed by: emaste, theraven, kib, markj (all previous version)
Differential Revision: https://reviews.freebsd.org/D41967


# d0b2dbfa 16-Aug-2023 Warner Losh <imp@FreeBSD.org>

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/


# c826e088 02-Aug-2021 Alex Richardson <arichardson@FreeBSD.org>

Fix MK_TESTS build with MK_ASAN/MK_UBSAN

Reviewed By: markj
Differential Revision: https://reviews.freebsd.org/D31049


# 194d5628 06-Oct-2020 Li-Wen Hsu <lwhsu@FreeBSD.org>

Make capsicum test cases fine-grained

Add a wrapping script to use ATF to run tests written with Googletest
one by one. This helps locating and tracking the failing case in CI easier.

This is a temporarily solution while Googletest support in Kyua is developing.
We will revert this once Kyua+Googletest integration is ready.

Reviewed by: emaste
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D25896


# 7cc42f6d 30-Sep-2020 Kyle Evans <kevans@FreeBSD.org>

Do a sweep and remove most WARNS=6 settings

Repeating the default WARNS here makes it slightly more difficult to
experiment with default WARNS changes, e.g. if we did something absolutely
bananas and introduced a WARNS=7 and wanted to try lifting the default to
that.

Drop most of them; there is one in the blake2 kernel module, but I suspect
it should be dropped -- the default WARNS in the rest of the build doesn't
currently apply to kernel modules, and I haven't put too much thought into
whether it makes sense to make it so.


# 08e5c473 29-Mar-2019 Olivier Cochard <olivier@FreeBSD.org>

Skip test if feature security_capabilities is not available

PR: 236863
Approved by: asomers
MFC after: 1 month
Sponsored by: Netflix


# 2216c693 30-Apr-2018 Ed Maste <emaste@FreeBSD.org>

Disable connectat/bindat with AT_FDCWD in capmode

Previously it was possible to connect a socket (which had the
CAP_CONNECT right) by calling "connectat(AT_FDCWD, ...)" even in
capabilties mode. This combination should be treated the same as a call
to connect (i.e. forbidden in capabilities mode). Similarly for bindat.

Disable connectat/bindat with AT_FDCWD in capabilities mode, fix up the
documentation and add tests.

PR: 222632
Submitted by: Jan Kokemüller <jan.kokemueller@gmail.com>
Reviewed by: Domagoj Stolfa
MFC after: 1 week
Relnotes: Yes
Differential Revision: https://reviews.freebsd.org/D15221


# 8ce99bb4 17-Apr-2018 John Baldwin <jhb@FreeBSD.org>

Properly do a deep copy of the ioctls capability array for fget_cap().

fget_cap() tries to do a cheaper snapshot of a file descriptor without
holding the file descriptor lock. This snapshot does not do a deep
copy of the ioctls capability array, but instead uses a different
return value to inform the caller to retry the copy with the lock
held. However, filecaps_copy() was returning 1 to indicate that a
retry was required, and fget_cap() was checking for 0 (actually
'!filecaps_copy()'). As a result, fget_cap() did not do a deep copy
of the ioctls array and just reused the original pointer. This cause
multiple file descriptor entries to think they owned the same pointer
and eventually resulted in duplicate frees.

The only code path that I'm aware of that triggers this is to create a
listen socket that has a restricted list of ioctls and then call
accept() which calls fget_cap() with a valid filecaps structure from
getsock_cap().

To fix, change the return value of filecaps_copy() to return true if
it succeeds in copying the caps and false if it fails because the lock
is required. I find this more intuitive than fixing the caller in
this case. While here, change the return type from 'int' to 'bool'.

Finally, make filecaps_copy() more robust in the failure case by not
copying any of the source filecaps structure over. This avoids the
possibility of leaking a pointer into a structure if a similar future
caller doesn't properly handle the return value from filecaps_copy()
at the expense of one more branch.

I also added a test case that panics before this change and now passes.

Reviewed by: kib
Discussed with: mjg (not a fan of the extra branch)
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D15047