mirror of
https://github.com/token2/snapd.git
synced 2026-03-13 11:15:47 -07:00
50fe4a9ec0
This will run a snap app with an attached gdbserver from the host. The app can run inside the confinement as a regular user and it can be debugged by running a gdb (or frontend) and attaching it to the running gdbserver. The app is run as the normal user and only the gdbserver is run as root. This allows debugging confined apps as well and it avoids the downside of the current "snap run --gdb" that requires to be run as root. It also allows attaching gdb frontends that can talk gdbserver. The setup is slightly involved: 1. snap run/snap-confine/snap-exec run normally 2. a new snap-gdbserver-shim is run that triggers "SIGSTOP" 3. gdbserver is attached once `snap run` got the SIGSTOP from the app. Note that at this point no application code was run yet so it does not matter if the app is using any of these signals 4. The attached gdbserver will interrupt the running app now. We can not do anything smart inside snap-gdbserver-shim.c (like waiting for an attached ptracer) because that would leak into the debug session. 5. Now gdb can get attached must send "cont", "signal SIGCONT" 6. With that setup gdb is right before the real app is exec()ed (just like with `snap run --gdb` today) There are some XXX inside this commit with ideas/questions about the UX but it should be usable and an improvement over the current `snap run --gdb`. If this looks good we could deprecate, remove or replace the existing `snap run --gdbserver`. The approach of attaching gdbserver from the outside instead of running gdbserver from snap-exec was taken to avoid having to open the ptrace syscall inside the confined app. This is what we would have to do if we just run gdbserver inside the sandbox that snap-confine setup for us.