config preflight exits 0 on allow_unauthenticated_users = true

Aberta Para iniciantes
  • Algo errado?
#5,090 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

@ericcurtin já está trabalhando nisso.

Desde 2/11/2026.

  • #5105 de @ericcurtin — aberto

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
70/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
rust
Domínio
cli

Direção de pesquisa

Encontre o subcomando openshell-gateway config preflight no código Rust, provavelmente um CLI crate. Inspecione a validação de configuração que atualmente sai com 0 e adicione um aviso quando allow_unauthenticated_users = true sob [openshell.gateway.auth]. Execute o preflight com essa configuração para confirmar que o aviso é impresso enquanto o código de saída permanece 0.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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.

Linguagem predominante
Rust
Estrelas
20.6k
Forks
2k
Merge médio
2d 13h
PRs com merge (30d)
262

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de NVIDIA/OpenShell

Todas as issues de NVIDIA/OpenShell

Issues semelhantes

Mais issues de Rust

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.