JDL — Resource-Modell

Status: Draft, aus dem Context-Modell herausgelöst Geltung: Was eine Runtime-Resource ist, wie Descriptor, Instanz und Handle getrennt werden, wie Contexts Resources binden und wie Ownership, Lifetime, optionale Autorität und Cross-Context-Transfer zusammenhängen. Nicht hier: Service-/Effect-Row-Semantik, Storage/MemoryRegion-Mechanik, Bridge-Oberflächen im Detail.

Kennzeichnung

Marke	Bedeutung
[N]	normativ, gilt
[D]	Entscheidung dieser Fassung
[O]	offen

---

Inhaltsverzeichnis

• 0. Auf einen Blick
• 1. Resource, Descriptor, Instanz und Handle [N]
• 2. ResourceBindingSpec gegen lebende Resource [D]
• 3. Services und Resources sind verschiedene Dinge [N]
• 4. Autorität als optionale Eigenschaft einer Resource [D]
• 5. Reserve für privilegierte Resources [D]
• 6. Autoritätsableitung und Attenuation [N]
• 7. Resource-Ownership, Lifetime und Autorität [N]
• 8. Parent-Binding ist Aktivierungssemantik [D]
• 9. Context-Bindung von Handles [N]
• 10. Cross-Context-Transfer [D]
• 11. CompilerInstance als Beispiel [D]
• 12. Spätere Folgerung: Sandboxing als Resource-Graph [O]
• 13. Minimale v0.1-Reserve
• 14. Normative Invarianten
• 15. Offene Punkte

0. Auf einen Blick

Eine Resource ist eine laufzeitgebundene Entität mit Identität und Lebensdauer. Manche Resources tragen zusätzlich konkrete Runtime-Autorität. Autorität folgt dann dem legitimen Besitz beziehungsweise der Erreichbarkeit des Resource-Handles, nicht einem globalen Berechtigungsflag.

ResourceDescriptor   kanonischer Vertrag
        ↓ provision / bind
ResourceInstance     lebender Runtime-Zustand
        ↓ referenziert durch
ResourceHandle       context-gebundener Zugriff

Nicht jede Resource ist sicherheitsrelevant. Eine MemoryRegion ist eine Resource, obwohl ihr Handle primär Lifetime und Ownership repräsentiert. Eine DirectoryResource, BridgeEndpoint oder CompilerInstance kann dagegen Autorität tragen.

1. Resource, Descriptor, Instanz und Handle [N]

Diese drei Ebenen dürfen nicht vermischt werden:

Ebene	Bedeutung
ResourceDescriptor	materialisierter, kanonischer Vertrag
ResourceInstance	lebende Runtime-Entität
ResourceHandle	adressierbarer Zugriff auf die Instanz

Ein Descriptor enthält keine lauf-lokale Handle-Identität. Ein ContextDescriptor kann daher nur beschreiben, wie eine Resource beim Aktivieren einer Context-Instanz bereitgestellt, übernommen oder abgeleitet werden soll.

Regel R-1. Laufende Resource-Handles sind Runtime-Zustand und niemals Bestandteil kanonischer Descriptor-Semantik.

2. ResourceBindingSpec gegen lebende Resource [D]

Der Context benutzt eine deklarative Bindungsspezifikation:

ContextDescriptor
└── resourceBindings: ResourceBindingSpec

Die konkrete Context-Instanz besitzt anschließend die aufgelösten Handles:

ContextInstance
└── resources
    ├── Handle A
    ├── Handle B
    └── ...

Eine Bindungsspezifikation kann konzeptionell beschreiben:

provision       beim Aktivieren neu bereitstellen
inherit         vom zulässigen Parent übernehmen
attenuate       aus einer vorhandenen Resource enger ableiten
bind            an einen Provider / Runtime-Slot binden

Die genaue Syntax ist offen.

Regel R-2. ResourceBindingSpec beschreibt Provisionierung und Erreichbarkeit; es ist keine Sammlung bereits lebender Resources.

3. Services und Resources sind verschiedene Dinge [N]

Service
    Was braucht Code semantisch?

Resource
    Welche laufzeitgebundene Entität existiert tatsächlich?

Eine Row führt Services. Resources sind keine Row-Elemente allein deshalb, weil ihre Handles zur Laufzeit existieren.

Beispiel:

FileSystem              Service
    ↓ arbeitet auf / liefert
DirectoryResource       Resource
    ↓ Handle trägt ggf.
read-only / read-write  Autorität

Der Service ist die semantische API. Die Resource ist der konkrete laufende Träger von Zustand, Lifetime oder Autorität.

4. Autorität als optionale Eigenschaft einer Resource [D]

In dieser Fassung gibt es kein separates globales CapabilitySet des Contexts. Daraus folgt nicht, dass v0.1 bereits ein allgemeines Capability-System implementieren muss.

Regel R-3. Falls Jade konkrete Runtime-Capabilities modelliert, haben sie einen Resource-Träger. Nicht jede Resource trägt sicherheitsrelevante Autorität.

Damit bedeutet Capability hier:

die konkrete Autorität, die über eine autoritätstragende Resource beziehungsweise ihr Handle ausgeübt werden kann.

Beispiele:

DirectoryResource("/srv/assets", read-only)
SocketEndpoint("api.example.com:443")
CompilerInstance(QueryOnly)
BridgeEndpoint(...)

Ein Handle vermittelt nur die Autorität, die sein Typ beziehungsweise ResourceDescriptor tatsächlich beschreibt; aus seinem Besitz folgt keine darüber hinausgehende Autorität.

5. Reserve für privilegierte Resources [D]

Für v0.1 reicht eine Reserve: Privilegierte Hostautorität soll später nicht aus einem Boolean, einem frei deklarierbaren Context-Feld oder einem gewöhnlichen Service-Provider entstehen müssen.

Regel R-4. Eine autoritätstragende Resource muss auf eine legitime Autoritätsquelle zurückführbar sein, sobald diese Autoritätssemantik implementiert wird.

Für Root-Domänen stammt diese Quelle letztlich aus dem Host Adapter beziehungsweise Ring 0. Für Kinddomänen stammt sie aus zulässiger Übernahme, Ableitung oder explizitem Transfer.

Host / Ring 0
    ↓ provision
Root Resource
    ↓ attenuate / derive
Child Resource
    ↓ transfer / lease
Remote Resource View

Die konkrete Host-/Linux-Erzwingung ist bewusst kein v0.1-Zwang.

6. Autoritätsableitung und Attenuation [N]

Monoton ist nicht die Menge der Resource-Objekte. Ein Kind darf selbstverständlich neue Resources erzeugen. Monoton ist die Autorität ihrer Ableitung.

Beispiel:

Parent:
DirectoryResource("/srv", read-write)

zulässige Ableitung:
DirectoryResource("/srv/public", read-only)

Unzulässig wäre:

read-only  → read-write
/srv/public → /srv

Regel R-5. Für jede autoritätstragende Ableitung muss gelten: authority(derived) ≤ authority(source).

Rein interne Resources ohne Hostautorität, etwa eine Scratch-Region, können lokal entstehen, sofern ihre Erstellung keine neue privilegierte Autorität mintet.

7. Resource-Ownership, Lifetime und Autorität [N]

Drei Fragen bleiben getrennt:

Existenz    Gibt es die Resource?
Ownership   Wer ist für ihr Lebensende verantwortlich?
Autorität   Wer darf welche Operationen über sie ausüben?

Ein Context kann eine Resource besitzen, ohne sie jedem Child erreichbar zu machen. Eine Nursery besitzt Tasks, nicht automatisch Runtime-Resources. Eine Resource kann wiederum intern Tasks besitzen.

Context
├── Root-Nursery          Task-Ownership
└── Runtime-Resources     Resource-Ownership
    └── EngineInstance
        └── Nursery       Task-Ownership

Regel R-6. Ownership begründet nicht automatisch Erreichbarkeit oder Autorität.

8. Parent-Binding ist Aktivierungssemantik [D]

Ein vertrauenswürdiger Parent kann einem Child beim Materialisieren beziehungsweise Aktivieren Resource-Bindings bereitstellen.

Parent Resource
    ↓ bind / attenuate bei Aktivierung
Child Resource Slot

Das ist kein allgemeiner Laufzeitkanal für Handle-Transfer.

Regel R-7. Parent-Expose von Resources ist Aktivierungsbindung. Nach der Aktivierung erfolgt neuer Cross-Context-Transfer ausschließlich über eine explizite Bridge-Transferform.

Damit bleibt die Trennung erhalten:

Parent-Expose   Aufbau der Umgebung
Bridge          Kommunikation / späterer Transfer

9. Context-Bindung von Handles [N]

Ein gewöhnliches Resource-Handle ist nur in seiner zulässigen Context-Domäne adressierbar.

Regel R-8. Ein Handle darf eine Context-Grenze nicht dadurch umgehen, dass seine Bits als gewöhnlicher Wert weitergereicht werden.

Der konkrete Ring-0-Mechanismus ist offen. Möglich sind Context-/Domain-Tags, Lease-Identitäten oder getrennte Handle-Klassen. Die Spec legt nur die beobachtbare Eigenschaft fest.

10. Cross-Context-Transfer [D]

Eine Bridge kann für Resources mindestens folgende Formen autorisieren:

Form	Bedeutung
Lease	zeitlich/logisch begrenzter Zugriff auf eine Resource der Quellseite
Transfer	Ownership und zulässige Adressierbarkeit wandern
SharedHandle	ausdrücklich geteilte Referenz mit eigener Lifetime-/Authority-Policy
Copy	nur für gewöhnliche Daten; erzeugt keine Resource-Identität auf der Gegenseite

Bei autoritätstragenden Resources ist Transfer zugleich Autoritätsübertragung.

Regel R-9. Transfer, Lease und Sharing dürfen Autorität nur erhalten oder attenuieren, niemals verstärken.

Die konkrete Repräsentation für local, thread, process und node bleibt offen.

11. CompilerInstance als Beispiel [D]

Eine laufende CompilerDB-Instanz ist eine privilegierte Resource:

CompilerInstance
├── Lifetime
├── Ownership
└── Compilerautorität

Ein ReplContext kann eine solche Resource gebunden erhalten. Ein gewöhnlicher Library-/Plugin-Context erhält sie nicht automatisch.

Soll sie über eine Context-Grenze verfügbar werden, gelten dieselben Regeln wie bei anderen autoritätstragenden Resources: Bindung, Attenuation, Lease, Transfer oder explizites Sharing.

12. Spätere Folgerung: Sandboxing als Resource-Graph [O]

Eine Sandbox lässt sich primär als eingeschränkter erreichbarer Resource-Graph verstehen:

ApplicationContext
├── Directory("/", rw)
└── NetworkRoot(*)

SandboxedContext
├── Directory("/tmp/app", rw)
└── NetworkRoot("api.example.com:443")

Der Sandbox-Context besitzt nicht bloß weniger Flags; er erhält tatsächlich nur engere Autoritätsträger.

Das ist eine spätere Folgerung, kein v0.1-Implementierungsauftrag: Eine solche Resource-Struktur könnte auf Linux-Sandboxmechanismen projiziert werden, ohne dass diese die JDL-Semantik definieren.

13. Minimale v0.1-Reserve

v0.1 muss noch kein allgemeines Capability-, Delegations- oder Sandboxing-System implementieren. Es sollte lediglich diese Sackgassen vermeiden:

Descriptor != Handle
Context-Bindung != ambienter Lookup
Parent-Binding != späterer Runtime-Transfer
Resource-Handle != gewöhnlicher Wire-Wert
privilegierte Host-Resource != frei mintbarer Anwendungswert

Damit kann die Autoritätssemantik später aus realem Bedarf heraus ergänzt werden, ohne das Resource-Modell umzubauen.

14. Normative Invarianten

1. Descriptor, Instanz und Handle sind getrennte Ebenen.
2. Kanonische Descriptoren enthalten keine lauf-lokalen Handle-Identitäten.
3. Rows führen Services; Resources sind Runtime-Entitäten.
4. Falls konkrete Runtime-Capabilities modelliert werden, besitzen sie einen Resource-Träger.
5. Autoritätstragende Resources müssen auf legitime Autoritätsquellen zurückführbar sein.
6. Ableitung und Transfer dürfen Autorität nicht verstärken.
7. Ownership, Existenz und Autorität sind getrennte Achsen.
8. Parent-Resource-Binding ist Aktivierungssemantik, kein späterer Transferkanal.
9. Resource-Handles sind context-gebunden.
10. Resource-Transfer über Context-Grenzen ist explizite Bridge-Semantik.

15. Offene Punkte

R-O1. ResourceDescriptor-Schema. Wie Autorität, Ableitungsregeln und Transferfähigkeit formal beschrieben werden.

R-O2. Attenuationsordnung. Welche Resource-Arten eine partielle Ordnung ihrer Autorität definieren und wie diese geprüft wird.

R-O3. Root-Provisionierung. Wie der Host Adapter privilegierte Root-Resources aus OS-Rechten materialisiert.

R-O4. Handle-Repräsentation. Wie Context-Bindung, Lease und SharedHandle in der JME repräsentiert werden.

R-O5. Autoritäts-Enforcement. Erst bei konkretem Bedarf festlegen, welche Hostmechanismen Resource-Autorität zusätzlich erzwingen.