|
Revision tags: release/13.4.0-p5, release/13.5.0-p1, release/14.2.0-p3, release/13.5.0, release/14.2.0-p2, release/14.1.0-p8, release/13.4.0-p4, release/14.1.0-p7, release/14.2.0-p1, release/13.4.0-p3, release/14.2.0, release/13.4.0 |
|
| #
6f636541 |
| 03-Sep-2024 |
Mark Johnston <[email protected]> |
capsicum tests: Serialize functional tests
The test suite runs the same tests twice, as different users, and these can trample over each other when run in parallel, causing spurious test failures.
capsicum tests: Serialize functional tests
The test suite runs the same tests twice, as different users, and these can trample over each other when run in parallel, causing spurious test failures.
MFC after: 1 week
(cherry picked from commit 41ece3c036bda3d4da321989ee59d0555c10d603)
show more ...
|
|
Revision tags: release/14.1.0, release/13.3.0, release/14.0.0 |
|
| #
d0b2dbfa |
| 16-Aug-2023 |
Warner Losh <[email protected]> |
Remove $FreeBSD$: one-line sh pattern
Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/
|
|
Revision tags: release/13.2.0, release/12.4.0, release/13.1.0, release/12.3.0 |
|
| #
c826e088 |
| 02-Aug-2021 |
Alex Richardson <[email protected]> |
Fix MK_TESTS build with MK_ASAN/MK_UBSAN
Reviewed By: markj Differential Revision: https://reviews.freebsd.org/D31049
|
|
Revision tags: release/13.0.0, release/12.2.0 |
|
| #
194d5628 |
| 06-Oct-2020 |
Li-Wen Hsu <[email protected]> |
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 tem
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
show more ...
|
| #
7cc42f6d |
| 01-Oct-2020 |
Kyle Evans <[email protected]> |
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 an
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.
show more ...
|
|
Revision tags: release/11.4.0, release/12.1.0, release/11.3.0 |
|
| #
08e5c473 |
| 29-Mar-2019 |
Olivier Cochard <[email protected]> |
Skip test if feature security_capabilities is not available
PR: 236863 Approved by: asomers MFC after: 1 month Sponsored by: Netflix
|
|
Revision tags: release/12.0.0, release/11.2.0 |
|
| #
2216c693 |
| 30-Apr-2018 |
Ed Maste <[email protected]> |
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. Th
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 <[email protected]> Reviewed by: Domagoj Stolfa MFC after: 1 week Relnotes: Yes Differential Revision: https://reviews.freebsd.org/D15221
show more ...
|
| #
8ce99bb4 |
| 17-Apr-2018 |
John Baldwin <[email protected]> |
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 no
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
show more ...
|