Page MenuHomeFreeBSD

disallow open(2) in capability mode
ClosedPublic

Authored by emaste on May 21 2017, 10:50 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 20 2024, 9:35 PM
Unknown Object (File)
Feb 9 2024, 4:25 PM
Unknown Object (File)
Jan 10 2024, 11:43 PM
Unknown Object (File)
Dec 22 2023, 9:46 PM
Unknown Object (File)
Sep 26 2023, 6:37 PM
Unknown Object (File)
Sep 17 2023, 3:45 AM
Unknown Object (File)
Aug 28 2023, 10:40 AM
Unknown Object (File)
Aug 28 2023, 10:37 AM
Subscribers
None

Details

Summary

Previously open(2) was allowed in capability mode, with a comment that suggested this was likely the case to facilitate debugging. The system would still fail, but it's better to disallow the syscall altogether. We can now use the kern.trap_enotcap sysctl to aid in debugging.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

This revision is now accepted and ready to land.May 21 2017, 11:03 PM

In addition libc calls openat() for open() as of rS277032

Sounds plausible, but I do wonder if the sysctl is currently a sufficient mature way to enable application development. Enabling it requires root, so it's not directly usable by end users on multiuser systems, and it also has global scope rather than just affecting applications that the developer is working on, which could change failure modes for a range of applications (such as desktop applications) that the developer has no interest in debugging and fixing. Is there some other mechanism we can add -- e.g., using ptrace(2) -- or setting an environmental variable that causes rtld to itself twiddle a per-process setting, that might offer a better real-world debugging experience?

Sounds plausible, but I do wonder if the sysctl is currently a sufficient mature way to enable application development. Enabling it requires root, so it's not directly usable by end users on multiuser systems, and it also has global scope rather than just affecting applications that the developer is working on, which could change failure modes for a range of applications (such as desktop applications) that the developer has no interest in debugging and fixing. Is there some other mechanism we can add -- e.g., using ptrace(2) -- or setting an environmental variable that causes rtld to itself twiddle a per-process setting, that might offer a better real-world debugging experience?

proccontrol(2) PROC_TRAPCAP_CTL and proccontrol(8) -m trapcap (the utility does not have a man page still).

This revision was automatically updated to reflect the committed changes.