[Lldb-commits] [PATCH] D144904: [Linux] Add kernel.yama.ptrace_scope note when ptrace fails to attach.

[Jordan Rupprecht via Phabricator via lldb-commits]

rupprecht added inline comments.


================
Comment at: lldb/source/Plugins/Process/Linux/NativeProcessLinux.cpp:235
+        std::error_code(errno, std::generic_category()),
+        "The current value of ptrace_scope is %d, which can cause ptrace to "
+        "fail to attach to a running process. To fix this, run:\n"
----------------
DavidSpickett wrote:
> Tell me if I understand correctly. This error is only used if you've already failed to attach. So if you had a value of 1 or 2, but attaching worked fine, you wouldn't see this.
> 
> Which is why you've said "which can cause" instead of "does cause". As there are some situations with 1 or 2 that do work.
That's exactly right, at least to my understanding.

Level 3 is basically a global kill switch -- no ptrace ever, in any context, even if you're root. The only way to undo that is to reboot, and even then, a hardened machine might set it to 3 in some startup config, so the only way to undo it is remove that setting and *then* reboot.

At level 2 you need `CAP_SYS_PTRACE` to ptrace an arbitrary process, i.e. you need to be root or have some root-like capability granted. So IIUC, `sudo lldb -n blah` should still work at that level.

At level 1, ptrace is allowed for anything LLDB launches, as there's a parent-child relationship, but usually not arbitrary other processes. However, an arbitrary process that wants to be debugged could call `prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...)` or `ptrace(PTRACE_TRACEME, ...)`, in which case a ptrace on that process should be successful. We could suggest these as other workarounds, but common advice is just to use `sudo sysctl -w kernel.yama.ptrace_scope=0`, and that's certainly a lot easier to fit into an error message.

Admittedly, using "which can cause" is sort of pedantic -- it can cause ptrace to fail, but there are situations above where it doesn't -- but failing in ptrace with EPERM followed by a non-zero ptrace_scope value is a very strong signal that this *is* the reason. I can't come up with a scenario where it isn't the case, but I this isn't my area of expertise.

The difference between 1 and 2 is subtle enough that I think we can use the same error message in each case, but if we also used it for level 3, that would just frustrate the user who tries to figure out why `sudo sysctl -w kernel.yama.ptrace_scope=0` doesn't work. But in general, I'd be happy with whatever wording people would find more useful.


================
Comment at: lldb/unittests/Process/Linux/ProcfsTests.cpp:113
+
+  // At this point we shouldn't fail parsing the core ids
+  Expected<int> ptrace_scope = GetPtraceScope();
----------------
DavidSpickett wrote:
> What do you mean by core ids?
Sorry, bad copy/paste from the test above.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144904/new/

https://reviews.llvm.org/D144904