# Bug report for bugs.kde.org

File at: https://bugs.kde.org/enter_bug.cgi?product=KRdp

- **Product:** KRdp
- **Component:** general
- **Version:** 6.7.0
- **Severity:** normal (regression)
- **OS:** Linux (reproducible on any distro; specifics below are Fedora 44)

---

## Summary

`NoNewPrivileges=true`, added to `app-org.kde.krdpserver.service` in commit `8e1de600a6ea4fcb1662508626da2cf0499f9734` ("Set NoNewPrivileges on the krdpserver systemd service"), breaks the `SystemUserEnabled=true` ("log in with your Linux account password") authentication path entirely. Every connection attempt fails PAM authentication regardless of whether the correct password is supplied, because the kernel-enforced `no_new_privs` flag prevents the setuid-root `unix_chkpwd` helper (which `pam_unix` depends on) from escalating privilege to read `/etc/shadow`.

This is a regression introduced between krdp 6.6.5 and 6.7.0. `SystemUserEnabled=true` worked correctly on 6.6.5 and has not changed; only the systemd unit changed.

## Environment

- krdp / krdp-libs: 6.7.0-1.fc44 (regression; 6.6.5-1.fc44 was the last known-working version)
- plasma-workspace: 6.7.0-1.fc44
- Distro: Fedora 44 (KDE Plasma 6.7.0 spin)
- systemd: 259.6-1.fc44
- pam: 1.7.2-1.fc44
- Desktop session: Wayland, KWin
- `/etc/shadow` permissions: `----------` (mode 000), owner root:root — standard Fedora default, not customized
- `/usr/bin/unix_chkpwd` permissions: `-rwsr-xr-x root root` — setuid-root, standard package default, not customized

## Steps to Reproduce

1. Install/upgrade to krdp 6.7.0 (e.g. via a routine `dnf upgrade` that pulls in plasma-workspace/krdp 6.7.0 together, as happens on Fedora).
2. In `~/.config/krdpserverrc`, set `SystemUserEnabled=true` under `[General]` (this is the "use my system account password" toggle, settable via the Remote Desktop KCM or directly).
3. Restart the server: `systemctl --user restart app-org.kde.krdpserver.service`.
4. From another machine, connect with an RDP client (tested with KDE's RDP client) using the correct username and the correct, current account password.
5. Observe the connection is rejected during authentication, every time, with the correct password.

## Observed Result

Every attempt fails identically. Relevant `journalctl --user -u app-org.kde.krdpserver.service` output for a single connection attempt:

```
New client connected:  Unspecified platform Unspecified version
unix_chkpwd[<pid>]: check pass; user unknown
unix_chkpwd[<pid>]: password check failed for user (james)
krdpserver[<pid>]: pam_unix(login:auth): authentication failure; logname=james uid=1000 euid=1000 tty= ruser= rhost=  user=james
krdpserver[<pid>]: pam_authenticate failure: Authentication failure
krdpserver[<pid>]: [ERROR][com.freerdp.api] - [rdp_peer_handle_state_active]: PostConnect for peer 0x... failed
krdpserver[<pid>]: [ERROR][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport->ReceiveCallback() - STATE_RUN_FAILED [-1]
```

The `unix_chkpwd: check pass; user unknown` line is notable: the account (`james`) unquestionably exists (`getent passwd james` resolves it fine; the same account is simultaneously logged in locally and over SSH at the time of the failed RDP attempt). This message corresponds to the helper's early-exit path, not a genuine "no such user" condition.

We confirmed this is reproducible across 5 separate connection attempts spanning two reboots, with the identical failure signature every time, ruling out a transient/network issue.

## Expected Result

Connecting with the correct system account username and password should succeed and authenticate the RDP session, as it did on krdp 6.6.5 under the identical account/PAM/shadow configuration.

## Root Cause Analysis

1. `app-org.kde.krdpserver.service` runs as a **per-user** systemd unit (`systemctl --user`), so `krdpserver` always runs as the unprivileged user (UID 1000 here), never as root. (This is necessarily true given krdpserver's job: it has to run inside the user's own graphical session to capture/control it.)
2. `SystemUserEnabled=true` authenticates via PAM: `src/RdpConnection.cpp` calls `pam_start("login", ...)` → `pam_authenticate()`.
3. Because the calling process (`krdpserver`) is not root, `pam_unix` cannot read `/etc/shadow` (mode 000, root-only) directly. Its normal fallback is to fork/exec `/usr/bin/unix_chkpwd`, a small setuid-root helper whose only purpose is to perform this one check on behalf of unprivileged callers — this is standard, expected `pam_unix` behavior on every distro, not a configuration quirk.
4. `NoNewPrivileges=true` is a kernel-enforced flag (`prctl(PR_SET_NO_NEW_PRIVS)`) that is inherited by the unit's main process and **all of its children**, and it unconditionally prevents privilege gain via `execve()` — including via setuid/setgid bits — for the lifetime of that process tree. This is explicitly what the directive is documented to do (and is quoted, accurately, in the commit message that added it).
5. So when `krdpserver` execs `unix_chkpwd`, the kernel refuses to honor the setuid-root bit. The helper runs as plain UID 1000, can't open `/etc/shadow`, and fails — before ever reaching the actual password comparison. This produces the generic, deliberately non-specific denial message (`check pass; user unknown`) that `unix_chkpwd`/`pam_unix` use to avoid distinguishing "no such user" from "couldn't check" to an unprivileged caller.

We verified this mechanism by diffing the unit file directly between releases:

- `v6.6.5`: https://github.com/KDE/krdp/blob/v6.6.5/server/app-org.kde.krdpserver.service.in — no `NoNewPrivileges` line.
- `v6.7.0`: https://github.com/KDE/krdp/blob/v6.7.0/server/app-org.kde.krdpserver.service.in — adds `NoNewPrivileges=true`.
- Introduced by commit https://github.com/KDE/krdp/commit/8e1de600a6ea4fcb1662508626da2cf0499f9734 (2026-05-15, no associated BUG: tag), whose own message states the goal is specifically to block setuid-based privilege escalation (citing `su`/"Copy Fail"-style exploit chains as the motivating threat) in case of a future FreeRDP RCE.

The hardening goal is legitimate and well-reasoned on its own; it simply doesn't appear to have been checked against the `SystemUserEnabled=true` code path, which depends on exactly the privilege-escalation mechanism it now blocks.

### Isolated mechanism test (confirmed)

To isolate the `NoNewPrivileges` mechanism from krdp itself (no krdp process, no real account password, no config changes), we invoked the `unix_chkpwd` helper directly, twice, with an intentionally wrong test password, with and without `no_new_privs` applied via `setpriv`:

```
$ printf 'isolatedtestbadpassword\0' | /usr/bin/unix_chkpwd james nonull
exit code: 7   (PAM_AUTH_ERR — "Authentication failure")
journal:   unix_chkpwd[6350]: password check failed for user (james)

$ printf 'isolatedtestbadpassword\0' | /usr/bin/setpriv --no-new-privs -- /usr/bin/unix_chkpwd james nonull
exit code: 9   (PAM_AUTHINFO_UNAVAIL — "Underlying authentication service can not retrieve authentication information")
journal:   unix_chkpwd[6404]: check pass; user unknown
           unix_chkpwd[6404]: password check failed for user (james)
```

The `setpriv --no-new-privs` run reproduces the exact journal signature seen in the live krdp failure (`check pass; user unknown`), and the PAM return code changes from a genuine "wrong password" result (`PAM_AUTH_ERR`) to "couldn't even check" (`PAM_AUTHINFO_UNAVAIL`) — with the only variable changed being the `no_new_privs` flag, nothing krdp- or config-related. This confirms the mechanism in isolation, independent of krdp's own code or our local `SystemUserEnabled` setting.

### Confirmed local workaround

Adding a systemd user-unit drop-in overriding the directive restores the pre-6.7.0 behavior:

```ini
# ~/.config/systemd/user/app-org.kde.krdpserver.service.d/override.conf
[Service]
NoNewPrivileges=false
```
followed by `systemctl --user daemon-reload && systemctl --user restart app-org.kde.krdpserver.service`.

This is offered as supporting evidence of the mechanism, not as a request to simply revert the hardening — see "Why this matters" below for why we think this needs an upstream decision rather than a per-user workaround.

## Why this isn't just "use the other auth mode instead"

KRdp's other authentication mode — a dedicated RDP-only username/password, stored via QtKeychain (which in practice resolves to KWallet/`ksecretd` on most KDE systems) — is not a substitute for `SystemUserEnabled=true` on a headless/unattended/autologin machine, for a structural reason:

- KWallet requires an interactive GUI prompt to unlock a locked wallet. There is no `org.kde.KWallet` D-Bus method that accepts a password to unlock non-interactively — by design.
- On a machine configured for unattended startup (no password typed at boot — e.g. SDDM/plasmalogin autologin), nothing ever supplies that unlock, so the wallet stays locked after every reboot.
- Since RDP is the remote-GUI-access method being relied on, and the wallet can only be unlocked via a prompt rendered on the graphical session, this is circular: you cannot unlock the wallet without GUI access, and you cannot get GUI access (via RDP) without the wallet already unlocked. Only physical presence at the console breaks the loop.
- We also confirmed current KWallet (`kwalletwizardpage*.ui` in the KDE/kwallet repo) offers no "no encryption / no prompt" wallet option — only Blowfish-with-password or GPG-key-backed wallets — so there is no supported way to configure the credential-store path to avoid this either.

So as of 6.7.0, there is no KRdp configuration — system-user or RDP-only-credential — that supports "reboot the machine remotely, then reconnect via RDP with nobody physically present," which we believe was a supported, intentional use case prior to this regression (it's explicitly accommodated by KRdp's own README, which documents SDDM autologin specifically for this purpose).

## Suggested directions for a fix (for maintainers to evaluate, not prescriptive)

- Don't apply `NoNewPrivileges=true` when `SystemUserEnabled=true` is in effect (runtime-conditional sandboxing), if that's mechanically feasible given the directive is normally fixed at unit-definition time.
- Or, move the privileged PAM check out of the sandboxed `krdpserver` process entirely — e.g. a small separate root-owned helper/D-Bus service that performs the `pam_authenticate()` call on krdpserver's behalf, so the hardening on the main (network-facing, untrusted-input-parsing) process can stay fully intact.
- At minimum, document the incompatibility so users relying on `SystemUserEnabled=true` for unattended access know this combination is currently non-functional, rather than discovering it via silent, mysteristically-worded authentication failures.

## Additional notes

- This is reproducible purely from the unit file change and standard Linux/systemd/PAM semantics (`/etc/shadow` mode 000, setuid `unix_chkpwd`, `NoNewPrivileges` semantics per `systemd.exec(5)`: https://www.freedesktop.org/software/systemd/man/latest/systemd.exec.html#NoNewPrivileges=) — we'd expect it to reproduce identically on any distro, not just Fedora.
- The isolated `unix_chkpwd`/`setpriv` test above (separate from the full local workaround, which bundles `SystemUserEnabled=true` together with the systemd override) confirms the mechanism on its own; raw output available on request.
- Full `journalctl --user -u app-org.kde.krdpserver.service` output and `dnf history` showing the exact 6.6.5→6.7.0 transition timestamp are available on request.