Skip to content
This repository has been archived by the owner on Jun 14, 2024. It is now read-only.

Updating remote process capture FAQ #44

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 47 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -101,9 +101,53 @@ Try clang instead of gcc (fingers crossed). See [clang comparison](http://clang.

#### How do I attach to a running process?

To be able to attach, the "attacher" needs to have special permissions. The
easiest method is to run a debug server as 'sudo' and connect to it.
See the question below.
To be able to attach, the lldb process needs to have a special capability called
[*process capture*]. By default, this is limited only to children processes of the
process doing the capture, which is the default way for `lldb` to work.
But, there are three strategies to enable "capturing" of a non-child process
by `lldb`.

The first one is to disable `pcap` scoping by setting the following value to 0:

```
echo 0 > /proc/sys/kernel/yama/ptrace_scope
```

But don't forget to set it back to `1` when you're done to keep your system safe.

The second one is to give your `lldb` executable the rights to capture non-children
processes by giving it a special capability (you'll need `libcap2-bin` installed):

```
sudo setcap cap_sys_ptrace=eip /usr/bin/lldb
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you test the plugin with this set? I ask this because the plugin is loading the debugger as a python library, and there is no /usr/bin/lldb process when running the plugin. So I can't see this change affecting the plugin.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you're right, I wrongly assumed the python library was still using the lldb binary… I'm changing this… At least that still applies to lldb-server ☺

I'll rewrite it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At least that still applies to lldb-server

Don't you think running lldb-server as root is more "secure" than escalating its capability? Or is there a significant usability improvement by doing that?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

well, it's a matter of personal choice, but yes I believe that it's still better from a security perspective, as running lldb-server as root gives a lot more than just remote process capture (basically r/w anywhere). So I believe it's worth noting in the FAQ

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as running lldb-server as root gives a lot more than just remote process capture

But that's limited to the text editor's scope. Another process cannot jack into the lldb-server process to access its capabilities. But changing the capability of lldb-server executable itself grants any process (that can execute it) with similar capabilities.

Copy link
Collaborator

@critiqjo critiqjo Jan 5, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC, there is an option to limit the number of clients to just one. (Not sure if it is the default.)

Update: Yes, it is the default. Passing --server option will make it fork for every incoming connection.

```

This cannot be reverted, so you can use user permissions to restrict the risk of
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cannot be reverted

What do you mean? Doesn't this work:

sudo setcap -r /usr/bin/lldb

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure but it's what I've read on the ubuntu forum link you've given and some other place… but because it was late, I've been a bit too fast at proposing the change ☺

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks like -r works, just tested. removing that 👌

getting lldb as a bounce to get your system hijacked.

The third one is to run `lldb` as root. Because that would mean running your entire
neovim session as root, this might not be a good idea. So then, you'd better run a
debug server as root, and see below how to do so.

N.B.: the above tips apply to the `/usr/bin/lldb-server` executable as well, if you
want to avoid running your debugger as root.

[*process capture*]:http://askubuntu.com/a/153970/583565

#### How to debug an interactive commandline process?

You'll need to make it possible to capture a remote process with `lldb`, see the above
answer for more details. And then, once your debugging session has been started, you
can run the following command to split a window, run your target program (called
*debugee* in the example below) within it and capture the process with lldb:

```
:vsplit term://./debugee | exec(":LL process attach -p " . b:terminal_job_pid)
```

Then you can setup breakpoints, watchpoints… and start the execution with `:LL continue`.

(don't forget to change `debugee` with your program name).

#### Remote debugging does not work!!

Expand Down