263 lines
5.4 KiB
Markdown
263 lines
5.4 KiB
Markdown
|
That sentence — **“any node can become a system”** — is actually the *right mental hook* for what you’re building. You’re just applying it at the **PEL + TGK semantic layer**, not the SystemRescue layer. That’s an important shift, and it exposes exactly the missing piece you’re feeling: **identity, authority, and certification**.
|
|||
|
|
|
|||
|
|
Let’s align the layers cleanly and then answer your question about **users, ownership, and whether ZFS helps**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. Re-anchoring “any node can become a system”
|
|||
|
|
|
|||
|
|
In your architecture, a **system** is *not* a machine and *not* a filesystem.
|
|||
|
|
A system is:
|
|||
|
|
|
|||
|
|
> **A domain that can produce, seal, snapshot, and attest to deterministic artifacts and executions.**
|
|||
|
|
|
|||
|
|
So:
|
|||
|
|
|
|||
|
|
* A laptop
|
|||
|
|
* A rescue USB
|
|||
|
|
* A build farm node
|
|||
|
|
* A CI runner
|
|||
|
|
* A forensics machine
|
|||
|
|
|
|||
|
|
…can *all* “become a system” **if** they can:
|
|||
|
|
|
|||
|
|
1. Produce artifacts/PERs
|
|||
|
|
2. Seal them
|
|||
|
|
3. Attach provenance
|
|||
|
|
4. Publish them under a domain identity
|
|||
|
|
|
|||
|
|
SystemRescue gives you *capability*.
|
|||
|
|
PEL + TGK give you *meaning*.
|
|||
|
|
What’s missing is **authority**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. What ZFS can and cannot do here
|
|||
|
|
|
|||
|
|
### What ZFS *can* help with
|
|||
|
|
|
|||
|
|
ZFS gives you:
|
|||
|
|
|
|||
|
|
* Snapshot identity (strong, immutable)
|
|||
|
|
* Retention pins
|
|||
|
|
* Integrity guarantees
|
|||
|
|
* A natural “domain-local root of persistence”
|
|||
|
|
|
|||
|
|
This makes ZFS an excellent **substrate for authority anchoring**.
|
|||
|
|
|
|||
|
|
### What ZFS cannot do
|
|||
|
|
|
|||
|
|
ZFS does **not** provide:
|
|||
|
|
|
|||
|
|
* Users
|
|||
|
|
* Identities
|
|||
|
|
* Ownership semantics
|
|||
|
|
* Certification
|
|||
|
|
* Trust relationships
|
|||
|
|
|
|||
|
|
ZFS can *host* trust anchors — it cannot *define* them.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. Users are not UNIX users (important)
|
|||
|
|
|
|||
|
|
If you try to map this to:
|
|||
|
|
|
|||
|
|
* `/etc/passwd`
|
|||
|
|
* UID/GID
|
|||
|
|
* POSIX permissions
|
|||
|
|
|
|||
|
|
You will break your own model.
|
|||
|
|
|
|||
|
|
In your system:
|
|||
|
|
|
|||
|
|
> **Users are cryptographic principals, not OS accounts.**
|
|||
|
|
|
|||
|
|
That’s the key.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. The missing layer: Domain Identity & Authority (DIA)
|
|||
|
|
|
|||
|
|
You are missing a small but crucial layer that sits **above ASL/PEL/TGK and below federation**.
|
|||
|
|
|
|||
|
|
Let’s call it (name optional):
|
|||
|
|
|
|||
|
|
> **Domain Identity & Authority (DIA)**
|
|||
|
|
|
|||
|
|
This layer defines:
|
|||
|
|
|
|||
|
|
* Who may *assert* artifacts
|
|||
|
|
* Who may *seal* snapshots
|
|||
|
|
* Who may *publish* state
|
|||
|
|
* Who may *certify* execution receipts
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. What a “user” actually is in your system
|
|||
|
|
|
|||
|
|
A **user** is:
|
|||
|
|
|
|||
|
|
> A keypair that is authorized to act *for a domain* under specific roles.
|
|||
|
|
|
|||
|
|
Not a login. Not a shell. Not a UID.
|
|||
|
|
|
|||
|
|
### Example roles
|
|||
|
|
|
|||
|
|
* `producer` — may generate artifacts
|
|||
|
|
* `executor` — may emit PERs
|
|||
|
|
* `publisher` — may publish snapshots
|
|||
|
|
* `auditor` — may verify, not write
|
|||
|
|
|
|||
|
|
Roles are **semantic**, not filesystem permissions.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6. Where identity lives (and yes, ZFS helps here)
|
|||
|
|
|
|||
|
|
### Domain identity root (per domain)
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
/asl/domain/
|
|||
|
|
├── domain.id
|
|||
|
|
├── domain.pubkey
|
|||
|
|
├── authorities/
|
|||
|
|
│ ├── root.pub
|
|||
|
|
│ ├── ci.pub
|
|||
|
|
│ └── rescue.pub
|
|||
|
|
├── policies/
|
|||
|
|
│ └── publish.policy
|
|||
|
|
└── attestations/
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
This lives:
|
|||
|
|
|
|||
|
|
* On ZFS
|
|||
|
|
* Inside a snapshot
|
|||
|
|
* Pinned
|
|||
|
|
* Immutable once sealed
|
|||
|
|
|
|||
|
|
This is your **domain root of trust**.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 7. Certification: what gets certified?
|
|||
|
|
|
|||
|
|
Not machines. Not users. Not files.
|
|||
|
|
|
|||
|
|
You certify **statements**.
|
|||
|
|
|
|||
|
|
Examples:
|
|||
|
|
|
|||
|
|
* “This snapshot represents `/home` as of logseq X”
|
|||
|
|
* “This PER was executed from these inputs”
|
|||
|
|
* “This artifact corresponds to this path”
|
|||
|
|
|
|||
|
|
These certifications are **artifacts themselves**.
|
|||
|
|
|
|||
|
|
That’s the big insight.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 8. Execution receipt certification (PEL + TGK)
|
|||
|
|
|
|||
|
|
A PER becomes authoritative only when:
|
|||
|
|
|
|||
|
|
1. Inputs are snapshot-bound
|
|||
|
|
2. Execution is deterministic
|
|||
|
|
3. PER is signed by an authorized key
|
|||
|
|
4. Signature is stored as an artifact
|
|||
|
|
5. TGK edge links PER → signature → snapshot
|
|||
|
|
|
|||
|
|
This gives you:
|
|||
|
|
|
|||
|
|
* Non-repudiation
|
|||
|
|
* Replayable verification
|
|||
|
|
* Cross-domain trust
|
|||
|
|
|
|||
|
|
No mutable ACLs. No global PKI required.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 9. Ownership is about *who can publish*
|
|||
|
|
|
|||
|
|
Ownership in your system is:
|
|||
|
|
|
|||
|
|
> The right to publish artifacts into a domain’s visible state.
|
|||
|
|
|
|||
|
|
That’s it.
|
|||
|
|
|
|||
|
|
* Anyone can *produce* internally
|
|||
|
|
* Only authorized keys can *publish*
|
|||
|
|
* Federation only sees *published* state
|
|||
|
|
|
|||
|
|
This matches your federation spec perfectly.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 10. What SystemRescue becomes in this model
|
|||
|
|
|
|||
|
|
SystemRescue is just:
|
|||
|
|
|
|||
|
|
> A transient node that can temporarily act under a domain identity.
|
|||
|
|
|
|||
|
|
It may:
|
|||
|
|
|
|||
|
|
* Import a domain key (hardware token, USB)
|
|||
|
|
* Produce recovery artifacts
|
|||
|
|
* Emit PERs
|
|||
|
|
* Publish a recovery snapshot
|
|||
|
|
|
|||
|
|
Then disappear.
|
|||
|
|
|
|||
|
|
The authority lives in the domain, not the machine.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 11. Why this completes “any node can become a system”
|
|||
|
|
|
|||
|
|
Because now:
|
|||
|
|
|
|||
|
|
* A node + tools + a key = a system
|
|||
|
|
* Without a key, it’s just a reader
|
|||
|
|
* With a key, it can assert truth
|
|||
|
|
* ZFS ensures what was asserted cannot be silently altered
|
|||
|
|
|
|||
|
|
That’s the closure you were missing.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 12. The minimal thing you need to add (not a big system)
|
|||
|
|
|
|||
|
|
You do **not** need:
|
|||
|
|
|
|||
|
|
* LDAP
|
|||
|
|
* OAuth
|
|||
|
|
* POSIX ACLs
|
|||
|
|
* Distributed consensus
|
|||
|
|
|
|||
|
|
You need:
|
|||
|
|
|
|||
|
|
* Domain keypairs
|
|||
|
|
* Signed artifacts
|
|||
|
|
* Snapshot-pinned authority state
|
|||
|
|
* Simple role policies
|
|||
|
|
|
|||
|
|
That’s it.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 13. One-sentence takeaway
|
|||
|
|
|
|||
|
|
> **ZFS gives you immutability; ASL gives you determinism; PEL gives you meaning; TGK gives you structure — but only cryptographic domain identity turns a node into a system.**
|
|||
|
|
|
|||
|
|
If you want, next we can:
|
|||
|
|
|
|||
|
|
* Specify a minimal **Domain Authority Manifest**
|
|||
|
|
* Define the PER signature format
|
|||
|
|
* Walk through “archived home directory” as a certified execution
|
|||
|
|
* Show how federation validates authority without trusting nodes
|
|||
|
|
|
|||
|
|
This is the missing keystone — and you were already circling it.
|
|||
|
|
|