config preflight exits 0 on allow_unauthenticated_users = true

未關閉 適合新手
#5,090 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

@ericcurtin 已經在處理了。

開始於 2026年11月2日。

  • #5105 來自 @ericcurtin —— 未關閉

評估

難度
2/5
預估耗時
1-3 小時
新手友好度
70/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
rust
領域
cli

研究方向

在 Rust 程式碼(可能是一個 CLI crate)中找到 openshell-gateway config preflight 子命令。檢查目前以 exit 0 退出的設定驗證,並在 [openshell.gateway.auth] 下當 allow_unauthenticated_users = true 時新增警告。使用該設定執行 preflight,確認警告印出的同時 exit code 保持為 0。

由索引模型根據 Issue 內容生成。

描述

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.

主要語言
Rust
星號
20.6k
分支
2k
平均合併
2 天 13 小時
30 天內合併 PR
262

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

NVIDIA/OpenShell 的其他 Issue

查看 NVIDIA/OpenShell 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。