[Bug 259778] Capsicum failures can raise only SIGTRAP
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 259778] Capsicum failures can raise only SIGTRAP"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 259778] Capsicum failures can raise only SIGTRAP"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 259778] Capsicum failures can raise only SIGTRAP"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 259778] Capsicum failures can raise only SIGTRAP"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 259778] Capsicum failures can raise only SIGTRAP"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 11 Nov 2021 13:57:00 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259778 Bug ID: 259778 Summary: Capsicum failures can raise only SIGTRAP Product: Base System Version: 13.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: bugs@FreeBSD.org Reporter: theraven@FreeBSD.org @emaste added a debugging mechanism using `procctl` that allows Capsicum failures to raise SIGTRAP. I am currently using this mechanism to provide a fallback mechanism that does an RPC to a privileged process, allowing me to run unmodified libraries in a sandbox. Unfortunately, SIGTRAP is caught by debuggers and not delivered to my process when it is being debugged. The analogous Linux mechanism in seccomp-bpf delivers SIGSYS, which is a lot more useful in this context. I would like to extend this mechanism to be able to deliver SIGSYS but before I do I wanted to open this bug to provide a space for some discussion. I see two possible implementation choices: - Allow the user to specify the signal that's raised. - Provide an option to raise SIGSYS instead of SIGTRAP. The former requires adding an extra field to `struct prot`, the latter could just consume an extra one of `p2_flags`, which would be easier to MFC. My leaning is towards the second (it requires less kernel state, is a smaller diff, and Linux doesn't give you any choice of signal), but if there's value in the more general mechanism then I can do that instead. If I go with the first mechanism, there's a question of what to do if both states are set. The simplest choice is to make them mutually exclusive (so setting `PROC_SIGCAP_CTL` [or whatever a more sensible name for it is] would clear `PROC_TRAPCAP_CTL` and vice versa). I can see it possibly being useful to enable both, so the debugger gets a signal and then the process gets a usefully catchable signal, in which case they'd need to be delivered in that order. -- You are receiving this mail because: You are the assignee for the bug.