run_script: Avoid requesting sudo password

[JoseExposito]

When running the MCP server over HTTP transport, _wrap_script() request the sudo password in the terminal.

Replace the current command to check if sudo fails with non-interactive mode. From the sudo help:

non-interactive mode, no prompts are used

Also, replace whoami with true, which simply return successfully, from its man page:

true - do nothing, successfully

Fixes: e6a05df ("RSPEED-2335 Wrap executed commands in sudo+systemd-run where possible (#256)")
Closes: #414

[github-actions]

For team members: test commit dbbf8f8 in internal GitLab

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

Flag	Coverage Δ
unittests	96.91% <100.00%> (+0.45%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
src/linux_mcp_server/connection/ssh.py	93.44% <100.00%> (ø)

... and 5 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[owtaylor]

Hmm, so one thing here is that I don't think local commands should ever be executed with a connection to a PTY.

Can you test:

-        proc = await asyncio.create_subprocess_exec(*full_command, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+        proc = await asyncio.create_subprocess_exec(*full_command, start_new_session=True, stdin=subprocess.DEVNULL, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

and in the local-execution path of ssh.py and see if that by itself fixes the problem. Perhaps we want --non-interactive in addition ... but the difference would be pretty small. I think sudo will never use anything but the terminal for prompting unless -A is explicitly passed in.

NOTE: once we have http mode fully supported, the plan is that local operation will be denied by default, since it's a potential security trap.

[owtaylor]

The use of sudo -l here is to avoid log noise. For me using sudo -l also prompts for the password and sudo -l --non-interactive also fails. Does that not work for you?

[JoseExposito]

The -l options works like this in my case (Linux), not sure if it might change in other OS (macOS or similar):

If no command is specified, the -l (list) option will list the allowed (and forbidden) commands for the invoking user (or the user specified by the -U option) on the current host.
If a command is specified and is permitted by sudoers, the fully- qualified path to the command is displayed along with any command line arguments.

For example:

$ sudo --non-interactive true
sudo: a password is required

$ sudo -l --non-interactive true
sudo: a password is required

$ sudo -l true
# Password is requested               
/usr/bin/true

[JoseExposito]

Can you test:

-        proc = await asyncio.create_subprocess_exec(*full_command, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
+        proc = await asyncio.create_subprocess_exec(*full_command, start_new_session=True, stdin=subprocess.DEVNULL, stdout=subprocess.PIPE, stderr=subprocess.PIPE)

and in the local-execution path of ssh.py and see if that by itself fixes the problem.

That works, and I think it is a cleaner solution. Let me update the MR to use your solution.

[github-actions]

For team members: test commit fb43755 in internal GitLab