This is a continuation for D8003.
Details
Details
- Reviewers
cem wblock - Group Reviewers
manpages - Commits
- rS306366: Editing fixes for r306257, documentation for trapcap.
Diff Detail
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 5302 Build 5484: CI src build Jenkins
Event Timeline
lib/libc/sys/cap_enter.2 | ||
---|---|---|
75–76 | is it sufficient to remove ", then for any process executing in a capability mode sandbox, "? After all, these errors only occur there. It simplifies the sentence but is maybe less clear if readers are unfamiliar with ENOTCAPABLE/ECAPMODE. |
lib/libc/sys/cap_enter.2 | ||
---|---|---|
75–76 | My feel is that a complicated sentence which provides explicit context is overall easier to understand _right_ than the simpler stripped-down statement, in this case. |
lib/libc/sys/cap_enter.2 | ||
---|---|---|
75–76 | Works for me. |
lib/libc/sys/cap_enter.2 | ||
---|---|---|
75–76 | What's more, [ENOTCAPABLE] may occur outside of capability mode, since capability rights are always respected. This might be useful when passing a file descriptor to a process with a lower privilege level. In this case, no SIGTRAP occurs. |
head/lib/libc/sys/cap_enter.2 | ||
---|---|---|
76 ↗ | (On Diff #20738) | s/either/either an/ |