[Mrigbozurike]

Why

rdc never needs root (the port is unprivileged, everything else happens in the desktop session), but nothing stopped it being started under sudo or from a system unit, and then the whole remote-control surface ran as root.

What

• rdc serve exits with a clear message if it is root. The decision is a pure function with tests.
• rdc doctor reports the process user and flags root.
• SECURITY.md and the README state the root policy and that nothing persists unless rdc service install is run explicitly.

Split out of the original #5 as requested; the [serve].user privilege drop is now its own PR built on top of this one. Verified on Linux (as root it refuses; as a user it serves) and Windows (builds, tests). Signed off.

[bscott]

Thanks. Refusing to run as root is right and I'd like to merge that part quickly.

The privilege-drop half is a lot of code for a case the PR itself says is only useful on X11, which nobody has tested yet, and set_var after the tokio runtime has started worker threads is undefined behaviour in Rust.

Could you split this into two PRs?

1. Refuse to run as root, with the doctor line. I'll merge that as soon as it's up.
2. The [serve].user drop as a separate PR, so it can be tested on an X11 box first.

Also, please sign off the commits (git commit -s).

[Mrigbozurike]

Split as requested. This PR is now just the root refusal + doctor line (317dbff, signed off). The [serve].user drop is in #13, rebuilt without set_var.

[bscott]

Thanks for the split, this is the right shape. One fix and a branch change:

1. It checks getuid() only. A setuid-root binary run by a normal user has euid 0 and passes. Please carry both uids, treat either being 0 as root, and add the two mixed-uid cases to the tests.

Small: the non-Unix current() invents uid 1000, which doctor then prints on Windows; print just the name there. And SECURITY.md's "rdc serve alone leaves nothing behind" is not quite true (it writes the audit log); "installs no service" is accurate.

Branch: we moved to release branches (see CONTRIBUTING). This goes into 0.5.0; please rebase onto release/0.4.0 (main.rs and CHANGELOG conflict, both trivial) and I will retarget the PR when release/0.5.0 exists. I would like to merge this one first.

[bscott]

0.4.0 is released and this PR's base is now release/0.5.0. Please rebase onto it (it is main as of v0.4.0).

[Mrigbozurike]

Fixed and rebased onto release/0.5.0, signed off.

1. Both uids. Current now carries uid and euid, and is_root() is true if either is 0 -- a setuid-root binary run by an ordinary user (uid 1000, euid 0) has every root privilege, and real-uid-0-with-dropped-euid can take it back with seteuid. Both mixed cases are tests (setuid_root_is_refused, root_with_dropped_euid_is_refused), along with the ordinary and both-zero cases.
2. No invented uid off Unix. The ids are Options, None on platforms that have no such concept, so is_root() is false there by construction rather than by guessing 1000. describe() prints alice (uid 1000), alice (uid 1000, euid 0) when they differ, or just alice where there are no uids -- which is what doctor shows on Windows. Covered by a test.
3. SECURITY.md corrected. It now says rdc serve installs no service, and that it does write the audit log and any --log-file under the user's state directory -- the previous "leaves nothing behind" was wrong.

Verified on Linux both ways: as root it refuses with the id in the message, and under setpriv --reuid=1000 doctor prints [ok ] process user: ubuntu (uid 1000).