Repository navigation
Harden the remaining account mutations against stale store data #13
Description
This issue originally tracked hardening the deletion path against stale store data. Deletion itself is gone: #25 replaced it with expiry and a retention purge, and everything else tracked here landed through #9, #19 and #22. The item-by-item audit is in the re-check comment.
The circuit breaker granularity item is dropped by decision: the 100% threshold stays, and since #25 the worst case behind it is a reversible mass lockout rather than data destruction.
SyncSupplementaryGroups trusts the store's UID
The handler (src/user_manager/backends/linux.rs) resolves via from_uid and replaces that account's supplementary groups. Since octosync owns the supplementary groups of synced users, a stale UID strips e.g. sudo from an unrelated account that happens to hold it.
- Route the mutating handlers through one shared resolver returning "missing", "matches" or "conflict", instead of the separate resolutions there are today:
UpdateUser,SyncSupplementaryGroups, and theresolve_account_checkedused byExpireAccountandPurgeAccount. Implemented in Replace account deletion with expiry and purge expired accounts after a retention period #25, which closes this issue.
Metadata
Metadata
Assignees
Labels
No labels
Activity
feat: Re-create missing accounts with the stored UID and sweep proces…
feat: Re-create missing accounts with the stored UID and sweep proces…
feat: Terminate user processes gracefully before killing them
feat: Keep deleted users as UID tombstones in a v2 users.json schema
feat: Preserve the primary group GID across delete and re-create
feat: Keep deleted users as UID tombstones in a v2 users.json schema
feat: Preserve the primary group GID across delete and re-create
feat: Preserve the primary group GID across delete and re-create
feat: Keep deleted users as UID tombstones in a v2 users.json schema
feat: Preserve the primary group GID across delete and re-create
feat: Never allocate a departed user's IDs to a brand-new member
jonasehrlich commentedon Aug 14, 2026
Re-checked every item against the #24 implementation (
je/expire-over-delete), as tracked there.Landed or superseded:
users,departedandpurged. Thehome_archivefield is gone again, since departure no longer archives — the expired account itself is the durable departure record.userdellives on inside the purge.save()never writes in a preview.Still open, not covered by #24:
SyncSupplementaryGroupsresolves by UID alone and replaces that account's groups, so a stale UID still strips groups from an unrelated account. The shared-resolver refactor (one resolver returning missing/matches/conflict forUpdateUser, the purge and this handler) remains to be done.would_expire_all_usersstill trips only at 100%. The severity dropped with Replace account deletion with expiry and purge expired accounts after six months #24 — the worst case is now a reversible mass lockout instead of mass deletion — but the item stands.[-]Harden user deletion and creation against stale store data[/-][+]Harden the remaining account mutations against stale store data[/+]