roster storage evolution: file (integrity-hardened) -> DB + RLS #800

Open
opened 2026-07-16 20:11:45 +00:00 by jason.woltje · 0 comments
Owner

Part of EPIC #796 (design-first).

Storage evolution for the roster store.

  • NOW: file-form roster acceptable IFF protected against malicious corruption — integrity, ownership, permissions (non-world-writable, owned by the runtime user).
  • LATER: DB-centric persistence when better; RLS on the DB where possible, ESPECIALLY in federated environments.

Security: roster write-path integrity is a secrev surface (a corrupted roster = attacker-controlled terminal embeds in the webUI). Design the file-form integrity model and the DB+RLS migration path. Coordinate with sub-issue 1 (data model) and stack#791 (ownership/permissions manifest).

Part of EPIC #796 (design-first). Storage evolution for the roster store. - NOW: file-form roster acceptable IFF protected against malicious corruption — integrity, ownership, permissions (non-world-writable, owned by the runtime user). - LATER: DB-centric persistence when better; RLS on the DB where possible, ESPECIALLY in federated environments. Security: roster write-path integrity is a secrev surface (a corrupted roster = attacker-controlled terminal embeds in the webUI). Design the file-form integrity model and the DB+RLS migration path. Coordinate with sub-issue 1 (data model) and stack#791 (ownership/permissions manifest).
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#800