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

[David Spickett via Phabricator via lldb-commits]

DavidSpickett accepted this revision.
DavidSpickett added a comment.
This revision is now accepted and ready to land.

LGTM



================
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"
----------------
rupprecht wrote:
> 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.
Sounds good to me. 

> At level 2 you need CAP_SYS_PTRACE to ptrace an arbitrary process

I've had this problem with docker containers started in certain ways, this error message will be really useful there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144904