Architecture

Three parts with different rights: the network-facing daemon has none, a small root helper checks passwords and starts sessions, and each session runs as the account itself.

how a login reaches a session
How a login reaches a session The client connects with TLS and RDP to the waydesk daemon, which has no privileges. The daemon asks the root helper, over a unix socket, to check the password and start a session. The helper starts the session as the account itself. The session sends screen, input, audio and clipboard back to the daemon. client FreeRDP, Windows App TLS, RDP network-facing, no privileges waydesk.service runs as: waydesk TLS, RDP, H.264 framing no PAM, no user files unix socket, peer credentials checked root, no network waydesk-helper.service runs as: root PAM check, memory admission starts the session as that account the account itself own logind session, own cgroup waydesk-session@UID runs as: the account sway (headless) capture, H.264 encode, input audio, clipboard shell, apps screen, input, audio, clipboard
no privileges

waydesk

does TLS, the RDP protocol, channel framing, rate limits per address.

never touches user files, calls PAM, keeps a password after the check.

root, no network

waydesk-helper

does checks the password through PAM, starts and finds sessions, admits or refuses by memory.

never parses RDP or TLS, listens on the network.

the account

waydesk-session@UID

does its sway, capture, encoder, input, audio, clipboard, hooks.

never anything as another user.

A session is a systemd unit of the account: it survives a disconnect, sits in user-UID.slice (limits there apply) and is killed with its control group. A second login from the same account takes the running session over. Design notes: docs/MULTIUSER-DESIGN.md.

This page is a file in the repository: corrections are welcome.