diff options
author | bptato <nincsnevem662@gmail.com> | 2024-10-31 17:44:03 +0100 |
---|---|---|
committer | bptato <nincsnevem662@gmail.com> | 2024-10-31 18:38:16 +0100 |
commit | d9ca197ed8056c021d4e37ec52aacc6039e24ab7 (patch) | |
tree | 782781c4bb85e65f112092f96c7ee91e447c7c97 /doc | |
parent | d9a74dbdeef846a98a464bfc102ce282b45e9606 (diff) | |
download | chawan-d9ca197ed8056c021d4e37ec52aacc6039e24ab7.tar.gz |
chaseccomp: fix compilation with newest dash, misc changes
* fix matching on unstripped whitespace: caught after upgrading to upstream dash & chaseccomp wouldn't compile * add defines to ensure that we computed the filter length correctly * inline cut_label * EPERM on sigaction, sigprocmask, gettid, and kill on tgkill (so a crash doesn't trigger sandbox violations) * move SIGSYS handler to C and add one for the network The last change removes the stack trace from SIGSYS, but gives us the syscall number which is probably more useful. (Indeed, we don't even have a stack trace in release builds.)
Diffstat (limited to 'doc')
-rw-r--r-- | doc/hacking.md | 22 |
1 files changed, 10 insertions, 12 deletions
diff --git a/doc/hacking.md b/doc/hacking.md index 99404064..12672fd1 100644 --- a/doc/hacking.md +++ b/doc/hacking.md @@ -212,18 +212,16 @@ Use `config.color.toml` and `my-test-case.color.expected` to preserve colors. ### Sandbox violations -First, note that a nil deref can also trigger a sandbox violation. Read -the stack trace to make sure you aren't dealing with that. - -Then, figure out if it's happening in a CGI process or a buffer -process. If your buffer was swapped out for the console, it's likely the -latter; otherwise, the former. - -Now change the appropriate sandbox handler from `SCMP_ACT_TRAP` to -`SCMP_ACT_KILL_PROCESS`. Run `strace -f ./cha -o start.console-buffer [...] 2>a`, -trigger the crash, then search for "killed by SIGSYS" in `a`. Copy the -logged PID, then search backwards once; you should now see the syscall -that got your process killed. +You got a syscall number (assuming you're on Linux); look it up in the +Linux syscall table for your architecture. + +To get more context on what happened, you can run +`strace -f ./cha -o start.console-buffer [...] 2>a`, trigger the crash, +then search for the last occurrence of "--- SIGSYS". Then search +backwards on the PID to see the last syscalls. + +(Incidentally, strace also shows the syscall name, so it may be easier +to check like that than looking it up in the syscall table.) ## Resources |