| b1db5e7b | 28-Aug-2019 |
Brooks Davis <[email protected]> |
MFC r348446:
makesyscalls.sh: always use absolute path for syscalls.conf
syscalls.conf is included using "." which per the Open Group:
If file does not contain a <slash>, the shell shall use the
MFC r348446:
makesyscalls.sh: always use absolute path for syscalls.conf
syscalls.conf is included using "." which per the Open Group:
If file does not contain a <slash>, the shell shall use the search path specified by PATH to find the directory containing file.
POSIX shells don't fall back to the current working directory.
Submitted by: Nathaniel Wesley Filardo <[email protected]> Reviewed by: bdrewery Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D20476
show more ...
|
| 08d94077 | 28-Aug-2019 |
Brooks Davis <[email protected]> |
MFC r340424:
Use the main capabilities.conf for freebsd32.
Allow the location of capabilities.conf to be configured.
Also allow a per-abi syscall prefix to be configured with the abi_func_prefix s
MFC r340424:
Use the main capabilities.conf for freebsd32.
Allow the location of capabilities.conf to be configured.
Also allow a per-abi syscall prefix to be configured with the abi_func_prefix syscalls.conf variable and check syscalls against entries in capabilities.conf with and without the prefix amended.
Take advantage of these two features to allow use shared capabilities.conf between the default syscall vector and the freebsd32 compatability layer. We've been inconsistent about keeping the two in sync as evidenced by the bugs fixed in r340294. This eliminates that problem going forward.
Reviewed by: kib Obtained from: CheriBSD Sponsored by: DARPA, AFRL Differential Revision: https://reviews.freebsd.org/D17932
show more ...
|
| de422137 | 16-Aug-2019 |
Kyle Evans <[email protected]> |
MFC r350464: kern_shm_open: push O_CLOEXEC into caller control
The motivation for this change is to allow wrappers around shm to be written that don't set CLOEXEC. kern_shm_open currently accepts O_
MFC r350464: kern_shm_open: push O_CLOEXEC into caller control
The motivation for this change is to allow wrappers around shm to be written that don't set CLOEXEC. kern_shm_open currently accepts O_CLOEXEC but sets it unconditionally. kern_shm_open is used by the shm_open(2) syscall, which is mandated by POSIX to set CLOEXEC, and CloudABI's sys_fd_create1(). Presumably O_CLOEXEC is intended in the latter caller, but it's unclear from the context.
sys_shm_open() now unconditionally sets O_CLOEXEC to meet POSIX requirements, and a comment has been dropped in to kern_fd_open() to explain the situation and add a pointer to where O_CLOEXEC setting is maintained for shm_open(2) correctness. CloudABI's sys_fd_create1() also unconditionally sets O_CLOEXEC to match previous behavior.
This also has the side-effect of making flags correctly reflect the O_CLOEXEC status on this fd for the rest of kern_shm_open(), but a glance-over leads me to believe that it didn't really matter.
show more ...
|