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

_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits

Reply via email to