Add the ability to run drgn against the live kernel as non-root user #347
Conversation
brenns10
force-pushed
the
sudo_fd
branch
2 times, most recently
from
8e8d809 to
16c1b4a
Compare
|
(Sorry for the force pushes, my pre-commit hooks weren't setup on my non-work laptop) |
brenns10
force-pushed
the
sudo_fd
branch
3 times, most recently
from
b6c19ee to
97cd2db
Compare
|
What I'm learning is that |
brenns10
force-pushed
the
sudo_fd
branch
3 times, most recently
from
be34dc7 to
cd58049
Compare
|
Thanks for the excellent review feedback, I'm so excited about this now! Try |
This allows an open file descriptor to be passed into Drgn and treated as a core dump. There are many use cases, but one interesting one is that the FD could be sent by a helper process running as root, allowing a non-root Drgn process to debug the running kernel. Signed-off-by: Stephen Brennan <stephen@brennan.io>
The files within /sys/module/*/sections seem to normally be 400 permissions, only accessible by root. Normally for live use, this is not a problem because we are running as root. However, if we're running as non-root, then we may get EACCES on these files. To handle this, fall back to using the non-live approach if we get an EACCES. Even if we do get the error, we can continue to use the /sys/module/*/notes files to maintain a partial speedup. Signed-off-by: Stephen Brennan <stephen@brennan.io>
Non-root users can now run Drgn against the running kernel. Drgn will attempt to use sudo to open /proc/kcore and transmit the opened file descriptor back to the user process. The file descriptor is then passed to Program.set_core_dump(). The user must still have sudo privileges. Signed-off-by: Stephen Brennan <stephen@brennan.io>
There was a problem hiding this comment.
There was still some funky indentation in kernel_module_section_iterator_init_no_sys_module, so I went ahead and fixed that and added "and program_from_core_dump()" to the commit subject for the first commit. I'll merge this now, thanks! This is a really nice feature.
|
Thanks for the quick cleanup, sorry I missed it! I'm already using this on my development machines so glad it can be in |
(As described in Slack)
/proc/kcorecan only be opened by root, so live debugging has been restricted to running drgn as root. But running drgn as root has downsides:PYTHONPATHdoes not include your home directorypycfiles as root (this can be avoided with-B)It would be very nice to be able to run Drgn as your current user, and only use escalated privileges to open
/proc/kcore. One approach would be to drop privileges after creating the program, which improves numbers 2 and 3. Unfortunately the PYTHONPATH, PATH, USER, and HOME environment variables would be unchanged, so much of the standard library would still believe you are root (e.g.getpass.getuser()). This can be worked around, but it's just a bit messy.Instead, we can run a helper program with sudo that will transmit the opened file descriptor back to Drgn via a Unix socket.
To do this, we add
Program.set_fd()andprogram_from_fd()which behave just likeset_core_dump(), etc, except they take the FD rather than the path.We add a helper script to do the "unix socket magic", and then we tie it all together in the CLI code. When the CLI code runs against the kernel, if it is not running as root, it will use the helper function to get the file descriptor. If the CLI is already running as root, nothing changes.
Running as non-root breaks drgn's module & section iterators, since drgn expects to be able to read data out of
/sys/modules-- unfortunately some of it has400permissions and can only be read by root. Thankfully, that code is just an optimized code path. We can disable that if we're running as a non-root user.Putting this all together, we have a way to run drgn as non-root user, and have all the features we've come to expect!