Running as root

[ktnlvr]

This is an attempt at reviving #488, #603, #646 and #872: Running and debugging as the root user.

From what I gathered there is a lot of busywork here already, so I volunteer to implement it myself. Mostly asking permission and hoping to show that it is actually necessary.

It seems like an important feature (see this, but to me personally too) and setting up an LLDB server every time is doable, but still an extra step.

I have a strong preference for this extension and would hate to see people go because of such a small inconvenience.

The current implementation idea is searching for local lifter like sudo/doas/rootdo and go using it. Will look for alternatives if that approach doesn't prove viable.

In the userspace an option like "sudo": true to maintain parity with Python's debugging seems sensible.

[puremourning]

I feel like this is something the client should facilitate rather than each and every server implement.

I say this, as a client maintainer, knowing it makes work for me.

In vimspector you can already automate running the gdbserver/lldb-server under sudo and connect to that. Is there a feature request to do similar in vscode? Can preRunTasks or whatever do that?

I get the use case. A number of people have requested it, but it seems a general automation/remote debugging problem rather than something every server should implement in various different ways. Thoughts?

[vadimcn]

@ktnlvr: what exactly is the problem with starting lldb-server? If you start it in platform mode you can then connect to it all day without having to do anything extra.

Starting a child process with elevated privileges is one of those things that can be expected to become a deluge of bug reports - it's done differently on each OS, potentially requires user input (and you'll want authentication state to be sticky, right?), and is constantly tinkered with by OS vendors "to improve security", which tends to break stuff.
I don't want to deal with all that for the sake of saving devs a few keystrokes in a relatively uncommon scenario.

[ktnlvr]

Thank you for the swift responses!

To address @puremourning's suggestion: I agree that this is a client responsibility. It is also doable using preRunTasks, but it is not very convenient. If it's used as a preRunTask directly it is possible to launch the lldb-server platform and then fork off it, but running the main task the next time will try to bind to the same port and crash.

In contrast, just making it a standalone task seems like a good option:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "Run LLDB Platform",
            "type": "shell",
            "command": "sudo lldb-server platform --server --listen '*:1234'"
        }
    ]
}

I do not have a windows machine on my hands, so I will assume that when doing privileged stuff it will ask from the user and this fix is not relevant to it.

Concerning @vadimcn's point, I understand the concern of dealing with fragile security-related code and it is for sure valid. But the question is again convenience and having something that nicely works out of the box. There is a reason as to why so many people are asking for it, and if the only roadblock was maintaining flimsy security I wouldn't be starting this discussion again.

If it is easy to implement as a task, there must be an easy way to run it as a launch flag.

If you don't find my argument convincing, I will also propose at least making a new palette command for generating an appropriate task and documenting that usecase in the manual.

[vadimcn]

You don't need to use preRunTask. Just open a terminal, type sudo lldb-server platform --server --listen *:1234 and leave it running.

There is a reason as to why so many people are asking for it,

Out of tens of thousands of CodeLLDB users, fewer than 10 have ever asked for this feature. I’d rather not add unnecessary features when the same result can be achieved with a bit of scripting.

That said, you’ve got a point about the documentation - this might be worth documenting.