This repository has been archived by the owner on Jun 14, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 20
Updating remote process capture FAQ #44
Open
guyzmo
wants to merge
3
commits into
dbgx:master
Choose a base branch
from
guyzmo:patch-1
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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 | ||
``` | ||
|
||
This cannot be reverted, so you can use user permissions to restrict the risk of | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
What do you mean? Doesn't this work:
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 ☺ There was a problem hiding this comment. Choose a reason for hiding this commentThe 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!! | ||
|
||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
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.There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?There was a problem hiding this comment.
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 FAQThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 oflldb-server
executable itself grants any process (that can execute it) with similar capabilities.There was a problem hiding this comment.
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.