gizmoduck: T3 federation design r4.8 for #414 (duckworth-0020 N22): R8 checks on 10.1.1.54 that mosaic has no sudo, no extra groups, no authorized keys and no sudoers.d entry

2026-10-20 14:31:06 -05:00
parent 2d3c3cfbdf
commit eb651aa68a
2 changed files with 5 additions and 2 deletions
@@ -1,6 +1,6 @@
 # T3 federation design: factory and hub (Vikunja #414, G3, G4, C1.1)

-Author Gizmoduck (Opus 5.5), 2026-10-20, r4.7. Design only, no product code. Reviewer Duckworth (Opus 5.5,
+Author Gizmoduck (Opus 5.5), 2026-10-20, r4.8. Design only, no product code. Reviewer Duckworth (Opus 5.5,
 mos-0978), r1 verdict changes B1-B5 (duckworth-0001, REVIEW.md at b402197ff), r2 verdict changes B6 (duckworth-0002,
 REVIEW-r2.md at 03a663cd7), r3 verdict changes B7 (duckworth-0003, REVIEW-r3.md at 45cbe5896), r4 verdict changes B8 (duckworth-0005, REVIEW-r4.md at
 4966136d4), r4.1 verdict changes, B8's issuer host (duckworth-0007, REVIEW-r4.1.md at b14f11136), r4.4 verdict changes B9 (duckworth-0010, REVIEW-r4.4.md at 4cf3ce232), r4.5 approved (duckworth-0012, REVIEW-r4.5.md at 912b1d325). R1, R2 and R5 go to Sage's
@@ -40,6 +40,8 @@ PLAN.md T3 (all in jason-master-restart).
  #419, section 8). N11, `#waiting` returns null for `to` `user` (3.6 item 7, R3).
  N12, R3 assumes nothing about how shares end (section 9 Q2). Row 196 (#1694, Gander) owns the shared
  principal verifier before R3 (section 5).
+- r4.8 (duckworth-0020 N22): R8 checks the hub user's limits on 10.1.1.54 instead of taking #421's plan
+  as done.
 - r4.7 (mos-1030, DECISIONS Q181): the hosts are settled. Case 1 is W-jarvis, 10.1.1.53 (VM 1008), the
  same host as the Hermes agents, so section 8 lists them as one factory host. The hub, Case 2, is
  W-Melanie-OC, 10.1.1.54 (VM 1012). Its OS user is `mosaic`, a system user with no sudo, no groups
@@ -523,7 +525,7 @@ gate. Chains follow Q177: a dependent row builds on its parent's candidate.
 | R4 | Revocation: 30 s timer, `access.reload` verb, claim end on loss, `threadsState` `revoked`, launcher skip and SIGTERM, launch check refusal, R5 calls `access.reload` | Codex Sol | R3, R5, row 193's viewer level (mos-1019) | bus and launcher tests, each with a mutant: a hand edit removing the grant ends the run within one timer period, an expiry with no request ends it, a pending message followed by a launcher restart starts no run, a running revoked thread gets SIGTERM, a grant downgraded to viewer counts as a loss, another user's runs stay. R4 starts after row 193's viewer level lands, because before it R1 refuses any other level, the whole file fails, and the downgrade test can't kill its mutant (N17, mos-1020) |
 | R6 | Console: granted-user sign-in, `user-cli` transport per session, per-request grant re-read, owner-only controls hidden, a notice on the user's thread page with row 193's sentence word for word (B9, N21): "The business owner sees your thread's agent's decisions, inbox entries, claims, tasks and project files, but not your messages.", peer links | Opus 5.5 | Sage #412 phase 1, R1, R2, R3 | webui tests on Sage's fake OP: granted user signs in, ungranted `sub` refused, revoked mid-session gets 401 on next call, a granted user's owner-verb call refused by the bus even with the UI check removed (mutant), the thread page's notice equals row 193's sentence exactly (N21) |
 | R7 | Scratch two-instance acceptance: two configs, two data roots, two Consoles, one fake OP. The Consoles start outside agent ancestry (a transient user unit), as the user proof requires. They never use the live stack's units or ports | Haiku 5.5 high | R1-R6, row 190 (several instances on one uid) | script test: Jason granted collaborator on one hub project signs in to the hub, makes a thread, sends to the granted instance, gets the instance's reply in the thread, is refused on another project and on board reads, is revoked and gets refused with the run ended. The factory shows nothing of the hub |
-| R8 | Live window, not a code row: hub provider client, hub proxy route, access.json written by Jason, re-pins | Jason, Mos | the hub host live (Vikunja #418), Jason's #419 answer, #412 phase 2, R7 | Entry gate, host form only for 10-27 (mos-0996): the hub runs on its own host (#418), not on dragon-lin or Melanie's server. R8 refuses to start unless every check passes. The hub is W-Melanie-OC, 10.1.1.54 (VM 1012), and its OS user is `mosaic`, with no sudo, no groups and no keys (Q181, #421). The privilege checks run on every factory host in section 8's list (the dragon-lin dev uid, and W-jarvis at 10.1.1.53, which is the Case 1 VM with its agents and the Hermes agents), as each factory uid there under `env -i`, and each passes only when the call fails: `sudo -n true`, `doas -n true`, and `ssh -o BatchMode=yes 10.1.1.54 true` as the hub user `mosaic`, as Jason's user and as root, each with and without the session's `SSH_AUTH_SOCK`. If `sudo -n` succeeds, as it does for jwoltje on dragon-lin (mos-0996 point 1), the factory counts as root on its own host. Then, as root through `sudo -n`: fingerprint every private key under every home and `/root`, and every key loaded in any agent socket found on the host (`ssh-add -l` per socket). Compare them with `ssh-keygen -lf` over every `authorized_keys` on the hub host, root's included, and no fingerprint matches. Run the ssh checks as root, once with no agent socket and once with each socket found, and each fails (N13). Every other privilege path is a named item in section 8's table (mos-1009): hypervisor, backups, sign-in provider, TLS front end, certificate authority, DNS and network. R8 refuses to start until each one is either closed, with its check passing, or accepted by Jason in writing with the table's wording, which also goes to Melanie (#419). The hub host's bus socket, data root and config dir don't exist on any factory host, no factory host mounts anything of the hub's, and the hub host runs no other instance or agent. Also: the two provider client ids differ, each origin answers over HTTPS from the other host, each Console reaches its issuer's discovery URL, and both clocks are synced. Jason's attestation confirms no factory agent holds a login or key for the hub host, but the failed calls are the gate. The uid form (row 190b) is a later option, outside this gate. Then Jason signs in to the hub from his account and sends one message, Melanie revokes, and his next request is refused |
+| R8 | Live window, not a code row: hub provider client, hub proxy route, access.json written by Jason, re-pins | Jason, Mos | the hub host live (Vikunja #418), Jason's #419 answer, #412 phase 2, R7 | Entry gate, host form only for 10-27 (mos-0996): the hub runs on its own host (#418), not on dragon-lin or Melanie's server. R8 refuses to start unless every check passes. The hub is W-Melanie-OC, 10.1.1.54 (VM 1012), and its OS user is `mosaic`, with no sudo, no groups and no keys (Q181, #421). #421's plan sets that, so R8 checks it on 10.1.1.54 as root and each must hold: `sudo -l -U mosaic` grants nothing, `id mosaic` shows only its own group, `~mosaic/.ssh/authorized_keys` is absent or empty, and no file under `/etc/sudoers.d` names it (N22). The privilege checks run on every factory host in section 8's list (the dragon-lin dev uid, and W-jarvis at 10.1.1.53, which is the Case 1 VM with its agents and the Hermes agents), as each factory uid there under `env -i`, and each passes only when the call fails: `sudo -n true`, `doas -n true`, and `ssh -o BatchMode=yes 10.1.1.54 true` as the hub user `mosaic`, as Jason's user and as root, each with and without the session's `SSH_AUTH_SOCK`. If `sudo -n` succeeds, as it does for jwoltje on dragon-lin (mos-0996 point 1), the factory counts as root on its own host. Then, as root through `sudo -n`: fingerprint every private key under every home and `/root`, and every key loaded in any agent socket found on the host (`ssh-add -l` per socket). Compare them with `ssh-keygen -lf` over every `authorized_keys` on the hub host, root's included, and no fingerprint matches. Run the ssh checks as root, once with no agent socket and once with each socket found, and each fails (N13). Every other privilege path is a named item in section 8's table (mos-1009): hypervisor, backups, sign-in provider, TLS front end, certificate authority, DNS and network. R8 refuses to start until each one is either closed, with its check passing, or accepted by Jason in writing with the table's wording, which also goes to Melanie (#419). The hub host's bus socket, data root and config dir don't exist on any factory host, no factory host mounts anything of the hub's, and the hub host runs no other instance or agent. Also: the two provider client ids differ, each origin answers over HTTPS from the other host, each Console reaches its issuer's discovery URL, and both clocks are synced. Jason's attestation confirms no factory agent holds a login or key for the hub host, but the failed calls are the gate. The uid form (row 190b) is a later option, outside this gate. Then Jason signs in to the hub from his account and sends one message, Melanie revokes, and his next request is refused |

 R1 can start now. R5 can be briefed now against R1's exported interface and lands after R1. R2 starts
 when Sage's #412 phase 1 candidate exists. R3 starts when R1 has a candidate, R4 when R3, R5 and row 193's viewer level do (mos-1019).
@@ -1371,3 +1371,4 @@ are never rewritten or removed; corrections are new entries.
 | 2026-10-20T19:20:55Z | Gizmoduck | T3 federation design r4.5 for #414 (duckworth-0010, mos-1022) | B9 user-thread decisions reach the owner's inbox by ruling, R3 tests it, N20 start order, R8 waits on host variables |
 | 2026-10-20T19:28:44Z | Gizmoduck | T3 federation design r4.6 for #414 (duckworth-0012 N21, morgana-0011) | R6 notice is row 193's sentence word for word, start-order line matches the table |
 | 2026-10-20T19:29:44Z | Gizmoduck | T3 federation design r4.7 for #414 (mos-1030, Q181) | hosts settled: Case 1 and Hermes on W-jarvis 10.1.1.53, hub W-Melanie-OC 10.1.1.54 user mosaic |
+| 2026-10-20T19:31:06Z | Gizmoduck | T3 federation design r4.8 for #414 (duckworth-0020 N22) | R8 checks mosaic's sudo, groups, keys and sudoers.d on 10.1.1.54 |