config preflight exits 0 on allow_unauthenticated_users = true

Open Beginner friendly
  • Is something wrong?
#5,090 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@ericcurtin is already working on this.

Since Nov 2, 2026.

  • #5105 by @ericcurtin — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
70/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
cli

Research direction

Find the openshell-gateway config preflight subcommand in the Rust code, likely a CLI crate. Inspect the config validation that currently exits 0 and add a warning when allow_unauthenticated_users = true under [openshell.gateway.auth]. Run the preflight with that setting to confirm the warning prints while exit code stays 0.

Written by the indexing model from the issue text.

Description

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.

Dominant language
Rust
Stars
20.6k
Forks
2k
Avg merge
2d 13h
Merged PRs (30d)
262

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/OpenShell

All issues in NVIDIA/OpenShell

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.