Fix filesystem paths for debugging process in containers

[clubby789]

Description/Motivation/Screenshots

When attaching to a process in a container, GDB prefixes file paths with target:, which means files can't be resolved. This also causes usage issues with output like

─────────────────────────────────────────────────────────────────────────────────── registers ────
[!] Command 'registers' failed to execute properly, reason: max() arg is an empty sequence
─────────────────────────────────────────────────────────────────────────────────────── stack ────
0x007ffd60a2b9b8│+0x0000: 0x007fdbeab206fa  →   pop rsi
0x007ffd60a2b9c0│+0x0008: 0x007fdbeab64b84  →  0x0000000000000000
0x007ffd60a2b9c8│+0x0010: 0x0000000000000000
0x007ffd60a2b9d0│+0x0018: 0x007ffd60a2ba28  →  0x00000000000003d6
0x007ffd60a2b9d8│+0x0020: 0x007fdbeab64b7c  →  0x0000000200000000
0x007ffd60a2b9e0│+0x0028: 0x00000000000000ee
0x007ffd60a2b9e8│+0x0030: 0x007fdbeab24782  →  <clock_nanosleep+77> pop rdx
0x007ffd60a2b9f0│+0x0038: 0x0000000000000000
─────────────────────────────────────────────────────────────────────────────── code:generic: ────
   0x7fdbeab23497                  mov    r9, QWORD PTR [rsp+0x10]
   0x7fdbeab2349c                  mov    QWORD PTR [rsp+0x8], r11
   0x7fdbeab234a1                  syscall 
[!] Command 'context' failed to execute properly, reason: 
gef>

This PR properly resolves file paths using /proc/$PID/root to access the process's filesystem root directory, making cross-container debugging much more usable.

Against which architecture was this tested ?

"Tested" indicates that the PR works and the unit test (i.e. make test) run passes without issue.

• x86-32
• x86-64
• ARM
• AARCH64
• MIPS
• POWERPC
• SPARC
• RISC-V

Note: I'm not sure if this can be reasonably tested automatically, as it would require being able to spawn extra containers in CI or use of chroot which may not be available in the CI. If testing is required please let me know how I can go about implementing a test.

Checklist

• My PR was done against the dev branch, not main.
• My code follows the code style of this project.
• My change includes a change to the documentation, if required.
• If my change adds new code, adequate tests have been added.
• I have read and agree to the CONTRIBUTING document.

[Grazfather]

Looks good. Could you maybe add an example on how you debug a target in a container to our docs? Do you use --pid=host?

[clubby789]

Looks good. Could you maybe add an example on how you debug a target in a container to our docs? Do you use --pid=host?

That's right. What about something of this form in the FAQ:

How can I use GEF to debug a process in a container?

GEF can attach to a process running in a container using gdb --pid=$PID, where $PID is the ID of the running process on the host. To find this, you can use docker top <container ID> -o pid | awk '!/PID/' | xargs -I'{}' pstree -psa {} to view the process tree for the container.

sudo may be required to attach to the process, which will depend on your system's security settings.

Please note that cross-container debugging may have unexpected issues. Installing gdb and GEF inside the container, or using the official GEF docker image may improve results.

[Grazfather]

Yes that's great.

[hugsy]

The patch looks great, thx @clubby789 Can you add some tests in dev/tests/api/gef_session.py ? A few checks (running local, running remote, and with qemu-user/qemu-system) should be enough.

[clubby789]

@hugsy Sorry, I'm not quite sure what the tests should be against. This patch isn't meant to effect Qemu since the VM's filesystem wouldn't be reachable

[clubby789]

I think installing qemu-user in the workflow should fix this?

[hugsy]

I think installing qemu-user in the workflow should fix this?

Correct, the last commit on dev fixed that.

[clubby789]

Are there any changes you'd like made here? Otherwise rerunning the CI should pass now

[hugsy]

just pull the latest changes from dev into your branch, then push it. it'll trigger the github actions again, which should pass yes

[clubby789]

Rebased onto latest dev

[hugsy]

Test on 18.04 not passing.
Looks weird tho

[clubby789]

That's weird. Locally, the PID of the process running under Qemu-user was 1, but that's not what happens on 18.04?

Maybe testing for /proc/[0-9]+/root would be better. I'll try and reproduce locally

[hugsy]

LGTM

[Ultimator14]

This removes some warnings but I get this error when attaching to gdbserver running in a container

Python Exception <class 'PermissionError'>: [Errno 13] Permission Denied: '/proc/15/root/lib64/ld-linux-x86-64.so.2'

Debugging works anyway so it's just a cosmetic issue.

[clubby789]

Running gdbserver in a container and attaching to it with gef-remote from the host has no issues for me. This code path shouldn't be hitting in remote mode 🤔

[Ultimator14]

gef-remote <host> <port> also works for me.
This only happens with target remote <host>:<port>

EDIT: Thanks for the hint that this is unsupported. Sorry for the inconvenience.

[theguy147]

LGTM

[hugsy]

Great PR, thanks!

This only happens with target remote :

EDIT: Thanks for the hint that this is unsupported. Sorry for the inconvenience.

No problem, the warning was actually added very recently because too many people were complaining that target remote failed with GEF, when GEF actually never supported it 😀