config preflight exits 0 on allow_unauthenticated_users = true

Offen Anfängerfreundlich
  • Stimmt etwas nicht?
#5,090 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

@ericcurtin arbeitet bereits daran.

Seit 02.11.2026.

  • #5105 von @ericcurtin — offen

Bewertung

Schwierigkeit
2/5
Geschätzter Aufwand
1-3 Stunden
Anfängerfreundlichkeit
70/100
Issue-Typ
Bug
Klarheit
Klar beschrieben
Aktivitätsstatus
Aktiv
Tech-Stack
rust
Bereich
cli

Rechercherichtung

Finde den openshell-gateway config preflight Unterbefehl im Rust-Code, wahrscheinlich einem CLI-Crate. Untersuche die Konfigurationsvalidierung, die aktuell mit 0 beendet, und füge eine Warnung hinzu, wenn allow_unauthenticated_users = true unter [openshell.gateway.auth]. Führe den Preflight mit dieser Einstellung aus, um zu bestätigen, dass die Warnung ausgegeben wird, während der Exit-Code 0 bleibt.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

state:triage-needed
Summary

openshell-gateway config preflight validates the shape of a configuration but not whether its choices are ones an operator should permit. In particular it exits 0, silently, on allow_unauthenticated_users = true — the one switch that turns v0.1.6's refusal-to-start-unauthenticated back into v0.1.5's warn-and-continue.

Measured on v0.1.6

Four arms, same binary, same host:

config result
valid config exit 0, silent
compute_driver = "not-a-driver" exit 1, category=malformed
malformed TOML exit 1
allow_unauthenticated_users = true under [openshell.gateway.auth] exit 0, silent
Why this seems worth a signal

v0.1.6 added the refusal to start without OIDC, mTLS user, operator auth, or gateway JWTs (#4814 — thank you, it is a real hardening over 0.1.5's warn-only behaviour). allow_unauthenticated_users is documented as the escape hatch for "trusted local development only", and that is a reasonable thing to provide.

The gap is that preflight is the tool an operator reaches for before starting the service, and it gives the same silent exit 0 for a correctly-authenticated configuration and for one that has opted out of authentication entirely. With the Docker compute driver the gateway holds a socket that is root-equivalent on its host, so the difference between those two configurations is not a small one.

Suggestion

A warning rather than a failure would fit the stated purpose: the switch is deliberate and documented, so failing preflight on it would break the development workflow it exists for. Something like

warning: allow_unauthenticated_users = true — inbound authentication is disabled
         (documented for trusted local development only)

would mean an operator who ran preflight cannot have missed it, and exit 0 would still hold for anyone who meant it. A --strict mode that failed on it would also work, if that fits the CLI's conventions better.

Related
  • #4814 introduced the refusal this switch opts out of.
  • #3959 reports adjacent preflight gaps on 0.1.2 — preflight not naming the offending key, and exit 0 on a configuration whose CreateSandbox calls then fail. That issue is about configurations that are invalid but unreported; this one is about a configuration that is valid but unsafe, which is why it is filed separately rather than as a comment there.

Happy to re-measure on a newer release if that is useful.

Vorherrschende Sprache
Rust
Sterne
20.6k
Forks
2k
Ø Merge
2 T. 13 Std.
Gemergte PRs (30 T.)
262

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus NVIDIA/OpenShell

Alle Issues in NVIDIA/OpenShell

Ähnliche Issues

Weitere Issues zu Rust

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.