enhancement
major
minor
defect
critical
major
minor
major
#30255
tl-ai-core: Der Agent-Zug wurde mit der Meldung „Objekte vom Typ … ohne Berechtigung erstellen“ zurückgesetzt, wenn ein Tool ein Teil in einem Objekt erstellt, das im selben Zug erstellt wurde – die doppelte Pre-Commit-Prüfung entfernen, Anfangswerte im TL-Script überprüfen
tl-ai-core 8.0.0-alpha12.819, Anwendung E-Home (haumacher/ehome #127).
Problem
Ein Agent-Tool (DATA_WRITE, ausgeführt in der Transaktion des Durchgangs) erstellt in einem einzigen Aufruf ein Objekt und dessen Bestandteile: ein Gebäude mit einem Stockwerk, die erste Verbindung eines Kommunikationsobjekts (ein neuer Connector, der eine neue Verbindung enthält) sowie ein dupliziertes Gerät mit seinen Parametereinstellungen. Die Transaktion wird durch den Pre-Commit-Guard zurückgesetzt:
Erstellen von Objekten vom Typ „ehome.building:Floor“ … ohne Berechtigung
Das Konto (Rolle „ehome.Installer“) darf beide Typen erstellen; dieselben Vorgänge sind von der Ansichtsebene aus erfolgreich.
Ursache
ModelSecurityPreCommitGuard.checkCreation fragt canCreate(type, container) in der festgeschriebenen Ansicht (withoutModifications) ab. Ein im selben Durchlauf erstellter Container existiert in dieser Ansicht nicht, und SecurityConfigurationService.isAllowedCreate stuft den Kontext als ungültig ein , da er als gelöscht gilt, bevor die eigene Regel für einen in der aktuellen Transaktion erstellten Kontext erreicht wird („nicht festgeschriebener Kontext -> erlaubt“).
Der Guard selbst ist ein Duplikat: Er stellt nachträglich – rekonstruiert aus dem Änderungssatz der Transaktion – erneut die Fragen, die die Engine bereits während des Schreibvorgangs der Tools stellt. TL-Script-Funktionen wie new(), set(), add(), remove() und delete() prüfen standardmäßig die Benutzerrechte (WithSecurityCheck), sodass ChangeDataTool- Skripte und TL-Script-Tools der Anwendung bei ihrer Ausführung überprüft werden; Remote-MCP-Tools schreiben in ihr eigenes System, außerhalb der Transaktion des Durchlaufs. Der vom Guard selbst durchgeführte Wechsel der Ansicht (committed-Ansicht für gelöschte Objekte, Transaktionsansicht für neue) hat zu der falschen Ablehnung geführt.
Die einzige Frage, die der Guard stellt und die sonst niemand stellt, ist das Recht, einen Anfangswert für ein neues Objekt festzulegen (#683): TL-Script set() fragt ModelAccessRights.isAllowed(..., WRITE) ab, was alle Aktionen für ein noch nicht festgeschriebenes Objekt zulässt; daher kann ein mit den Benutzerrechten ausgeführtes Skript ein Attribut eines neuen Objekts festlegen, das der Benutzer in den Erstellungsdialogen nicht festlegen dürfte.
Lösung
- Die Pre-Commit-Prüfung wird aus tl-ai-core entfernt (PreCommitGuard, ModelSecurityPreCommitGuard, deren Aufrufe in AgentLoop und im McpToolAdapter des MCP-Servers, deren Tests sowie der dazugehörige Entwicklerartikel). Ein Agent-Durchlauf führt das Commit der von seinen Tools unter den Rechten des Benutzers geschriebenen Daten durch; die eigenen Prüfungen der Tools (Java-Tools über ModelSecurity, TL-Script über die Engine) bilden die Sicherheit eines Schreibvorgangs. ToolChangeSet bleibt bestehen, es bildet die Grundlage für den Änderungsbericht der Schreib-Tools.
- Update.checkWritePermission (die Schreibprüfung von TL-Script und der Speicherpfade der Ansichtsebene) fragt bei einem noch nicht festgeschriebenen Objekt ModelAccessRights.isAllowedInitial ab – genau die Frage, die die Erstellungsdialoge stellen –, anstatt isAllowed. Ein mit den Rechten des Benutzers ausgeführtes Skript kann keinen Anfangswert mehr festlegen, den der Benutzer nicht festlegen darf.
Migration
- Ein Anwendungsskript, das mit Sicherheitsüberprüfung ausgeführt wird (Standardeinstellung) und ein Attribut mit einer WRITE-Berechtigung auf Attributebene für ein in derselben Transaktion erstelltes Objekt festlegt – z. B. ein Feld „Erstellt von“, das der Benutzer nicht bearbeiten darf –, wird nun für einen Benutzer ohne diese Berechtigung abgelehnt. Entweder gewähren Sie der Rolle das Recht auf das Attribut oder führen Sie das Skript ohne Sicherheitskontext aus.
- Workarounds für die fälschliche Ablehnung durch den Pre-Commit-Guard (z. B. eine SecurityContextFactory, die canCreate für einen im selben Durchlauf erstellten Container mit „yes“ beantwortet) können entfernt werden.
- Die Klassen com.top_logic.tl.ai.core.security.PreCommitGuard und ModelSecurityPreCommitGuard entfallen. Eigener Code, der sie verwendet oder implementiert, entfernt diese Verwendungen; die Schreibrechte prüfen die Werkzeuge selbst (Java-Werkzeuge über ModelSecurity, TL-Script über die Engine).