[Bug 259778] Capsicum failures can raise only SIGTRAP

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259778

--- Comment #3 from David Chisnall <theraven@FreeBSD.org> ---
I have:

1. Added a new `procctl` verb `PROC_SIGCAP_CTL` that sets a bit in `p_flag2`.
2. Added a SIGCAP that will be delivered on Capsicum violations.
3. Delivered SIGCAP if this bit is set, *after* delivering `SIGTRAP` (so that
the debugger can see the failure and then the process can catch it).

I am not sure if (3) is the correct sequence.  When I'm debugging these things
I probably actually want to get the SIGTRAP after the SIGCAP, and only if the
SIGCAP doesn't handle the failure, but I have no mechanism for signalling this
to the kernel, so I'd most likely just stick a breakpoint at the end of my
signal handler and ignore SIGTRAP entirely.

Unfortunately, it turns out that I don't understand the signal delivery logic. 
Calling `trapsignal` twice does not appear to work: If I request either signal,
everything works fine in my test program, but if I request both then my test
fails.  Unfortunately, the child process fails in startup with gdb attached on
-CURRENT.

In a reduced test case, where I set both flags, then do `cap_enter` and `open`
with trivial signal handlers that just print the signal that's delivered, I see
SIGTRAP arriving *before* SIGCAP.  This is my modification to the syscall
return path:

https://github.com/davidchisnall/freebsd-src/blob/5329f8fc0bb881f9172c790097c975f3429f6d67/sys/kern/subr_syscall.c#L225


I believe I need to do more to deliver two signals, synchronously, which is why
I didn't want to allow both mechanisms to exist, but I don't know what the
extra work I need to do is and the `trapsignal` man page is not illuminating.

-- 
You are receiving this mail because:
You are the assignee for the bug.