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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
