Merge pull request 'Issue 247: a module cannot put the operator's account in a group' (#99) from issues/247-a-module-cannot-put-the-operator-in-a-group into main

2026-10-05 13:45:52 +00:00
parent 855c3f9b33 f93b02900c
commit ae58570209
1 changed files with 52 additions and 0 deletions
@@ -0,0 +1,52 @@
+---
+status: open
+opened: 2026-10-05
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 247 — A module cannot put the operator's account in a group
+
+## What was observed
+
+2026-10-05. The module for a peripheral-lighting daemon was assigned to the laptop. Its package
+installs the daemon and creates the daemon's group. The daemon then refuses to start: "User is not a
+member of the openrazer group". The device files are the group's, so the daemon cannot reach the
+devices.
+
+The module's own check names the fix, which is to add the account to the group and log in again. No
+module can declare that fix:
+
+- The account is a `user` resource, and the login-shell module already declares it, to set its shell.
+- A second module that declares the same account, only to add one group, is refused as a duplicate
+  name.
+- There is no resource for one membership on its own. A whole-account declaration that lists groups
+  would also take from the account every group it does not list, including the operator's own.
+
+So the step is done by hand, with `sudo`, outside the mesh, and nothing records why the account is in
+the group.
+
+## Why it matters beyond this instance
+
+More modules need this than this one: input devices (`input`), serial ports (`uucp`), the container
+runtime (`docker`), virtual machines (`libvirt`, `kvm`), and capture or scanner hardware. Each is a
+fact a module knows and the operator's account needs. Today every one is a hand step that survives a
+reinstall only by memory. A membership added by hand is also never taken away when the module that
+needed it is unassigned.
+
+## Open questions
+
+1. Is a membership its own resource (account, group), held by the module that needs it and given
+   back on undeclare? Or is it a contribution to the account's holder, in the way ADR 0212 lets a
+   module contribute to a seat?
+2. A membership takes effect at the next login. How does the module say so: a finding, or a
+   moment the power or session seat already knows?
+3. What does undeclare do with a membership the account already had before any module declared it?
+   The host keeps what it found and gives it back, as it does with a whole file it wrote over.
+
+## How it is checked
+
+When fixed, assigning the lighting module to a machine whose account is not in the group puts the
+account in the group, says that a new login is needed, and leaves the account's other groups as they
+were. Unassigning it removes only a membership the module added.