Page MenuHomeFreeBSD

disallow open(2) in capability mode
ClosedPublic

Authored by emaste on May 21 2017, 10:50 PM.

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
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

emaste created this revision.May 21 2017, 10:50 PM
kib accepted this revision.May 21 2017, 11:03 PM
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

rwatson accepted this revision.May 22 2017, 6:33 AM

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?

kib added a comment.May 22 2017, 9:41 AM

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.