fix(security): restrict logic graph mutations to admin users

[Micsi]

Motivation

• The runtime starts persistent asyncio cron tasks for enabled timer_cron nodes from stored graphs, and graph creation/update was previously permitted for any authenticated user, enabling low-privilege actors to persist scheduled background tasks and unattended datapoint writes.
• Apply minimal authorization hardening at the API entrypoints where attacker-controlled graphs are written to the database to prevent persistent abuse while preserving scheduler and executor logic.

Description

• Import get_admin_user and require it instead of get_current_user in obs/api/v1/logic.py.
• Changed dependency for the mutation endpoints create_graph, update_graph_full, update_graph_partial, delete_graph, import_graph, and duplicate_graph to use Depends(get_admin_user) so only admin users can persist or modify graphs.
• Left read and manual-run endpoints (list_graphs, get_graph, export_graph, run_graph) as get_current_user to keep non-persistent operations available to authenticated users.
• No changes to the scheduler (obs/logic/manager.py) or execution paths beyond this authorization boundary.

Testing

• python -m compileall obs/api/v1/logic.py succeeded for the modified file.
• Attempts to run relevant pytest suites (tests/unit/test_logic_rename.py and integration suites) failed in this environment because the pytest-asyncio plugin is not installed, so async tests could not be executed here.
• The change is intentionally minimal to limit risk and preserve existing behavior for non-mutating operations.

---

Codex Task

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ac4150c16c

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Allow admin API keys on graph mutation routes

Switching these endpoints to Depends(get_admin_user) breaks all API-key based automation: get_current_user resolves API keys to api_keys.name (not the owning username), and get_admin_user then checks users.username = current_user, which returns no row and raises 403 for every API key request. This means even keys owned by admin users can no longer create/update/delete/import/duplicate graphs, which is a regression for script-driven management workflows.

Useful? React with 👍 / 👎.

[Micsi]

Danke für den Security-Fix. Kurze Einordnung zu Risiken/Folgen, damit wir die offene Berechtigungsentscheidung im Team sauber treffen:

Was dieser PR konkret verbessert

• Mutationen an Logic-Graphs sind jetzt auf Admin begrenzt (create, update, patch, delete, import, duplicate).
• Damit ist die direkte Manipulation der Graph-Definition durch normale User geschlossen.

Was weiterhin bewusst offen bleibt (und Security-relevant ist)

• Normale User können weiterhin Graphen lesen/listen/exportieren und vor allem ausführen (POST /logic/graphs/{id}/run).
• Ohne Ownership-/ACL-Modell bedeutet das: Ein normaler User kann potenziell auch fremde bzw. Admin-Graphen triggern.

Folgen für den Betrieb

• Positiv: deutlich kleinerer Angriffsraum für persistente Manipulationen.
• Weiteres Risiko: Laufzeit-Effekte über run bleiben möglich (je nach Graph-Inhalt und Node-Typen).
• Produktseitig konsistent, wenn wir „Cron/Trigger auch für normale User“ explizit wollen.

Offene Architekturfrage (Team-Entscheidung)

• Wollen wir bei run global bleiben (alle Auth-User dürfen alle Graphen ausführen)?
• Oder auf Owner/ACL umstellen (z. B. Owner + explizite Freigabe pro Graph)?
• Optional: separates Recht „execute“ vs. „mutate“ statt nur admin/non-admin.

Empfohlene nächste Schritte (unabhängig von der Grundsatzentscheidung)

• Explizite 403-Regressionstests für alle neuen Admin-geschützten Endpunkte ergänzen.
• Entscheidung zu Ownership/ACL für run und export festziehen, bevor weitere Features darauf aufbauen.