activator: spawned instances get no supplementary groups (initgroups is never called) Issue open
Migrated from github.com/carlosframework/platform issue #139, opened 2026-08-10. GitHub issues are closed for this repo; see AGENTS.md, "Work is tracked on amadan, not GitHub".
Still outstanding: Activator-spawned instances get no supplementary groups, so anything shared by group permission silently fails.
---
Observed live on carlos-tito-ie (2026-08-10) while wiring titogo's platform-provisioned instances to the fleet's OAuth connect relay.
What happens: an activator-spawned instance process runs with only its primary group:
$ grep -E '^(Uid|Gid|Groups)' /proc/<instance-pid>/status
Uid: 999 999 999 999
Gid: 989 989 989 989
Groups: 989usermod -aG titogo carlos followed by a respawn changes nothing — the spawned process still carries only gid 989. The activator evidently calls setuid/setgid without initgroups(3) (or an equivalent setgroups from /etc/group), so group membership granted to the instance user never reaches instance processes.
Why it matters: any unix resource an app shares with its instances via group permissions silently fails. Concrete case: titogo's connect relay listens on a 0660 unix socket owned titogo:titogo; platform instances (uid carlos) could not dial it even after being granted the group, and every activator-spawned account's Integrations page reported the connection service unavailable. runuser -u carlos -- curl --unix-socket … from a login context (which does initgroups) succeeds against the same socket — the membership is right, it just never reaches the spawned process.
Workaround in place (titogo): the relay chgrps its socket to the instances' primary group (TITO_RELAY_SOCKET_GROUP=carlos, teamtito/titogo#746) — workable, but it forces the sharing app to know the platform's user layout, and only covers the one-socket case.
Suggested fix: initgroups(3) (or setgroups computed from the group database) at spawn, matching what login/systemd User= both do — carlos-app@ units already get supplementary groups from systemd, so exec-model instances behave differently from unit-model ones today, which is its own surprise.
🤖 Generated with Claude Code