carlos / platform Public

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: 989

usermod -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