rdp-server: GPU groups granted to service account only, handover daemon loses access

[catinspace-au]

Summary

roles/rdp-server/tasks/gpu_groups.yml removes the world-open udev rule and replaces it with group membership, but grants those groups only to the gnome-remote-desktop service account:

- name: Grant gnome-remote-desktop GPU access via render/video groups
  ansible.builtin.user:
    name: gnome-remote-desktop
    groups: render,video
    append: true

followed by

- name: Remove legacy world-open GPU udev rule
  ansible.builtin.file:
    path: /etc/udev/rules.d/99-gpu-open-access.rules
    state: absent

The gap

With the remote-login handover path there are two daemons, and they run as different identities:

• /usr/libexec/gnome-remote-desktop-daemon --system, running as gnome-remote-desktop
• /usr/libexec/gnome-remote-desktop-daemon --handover, running as the logged-in desktop user

The handover daemon is the one that captures and encodes the user's session, and it is the one holding the render node and the NVENC session. It is not covered by the group grant.

Impact

On a host where GPU access came from the MODE="0666" rule, removing that rule without adding the desktop user to render/video means the handover daemon loses access to the render node once the device nodes are recreated. The running session survives on already-open file descriptors, so the failure does not appear until the next login, when hardware encode silently drops to software.

Observed on Ubuntu 26.04: both render and video were empty groups, and /dev/dri/* was crw-rw-rw- solely because of the udev rule.

Suggested fix

Add the target desktop user (the role already resolves actual_user) to render and video alongside the service account, before removing the udev rule. A note that group membership only takes effect on next login would also help, since the role cannot verify the result within the same run.