Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Policy selection is nondeterministic when several policies allow one image; add container_names routing and deny on ambiguity

Chiusa
  • Qualcosa non va?
#85 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #90 di @abienkowski — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
18/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
docker, go, rust, typescript
Ambito
api, security

Direzione di ricerca

Start from GetByImage, which returns the first matching policy while iterating a map, and from the POST /containers/create handler that uses its result. Adding container_names routing and load-time ambiguity checks touches all three implementations and the Quint model. Pull request #90 is already open against this issue, so check it before starting. Done means the same image and name always select one policy, and ambiguous matches return 403.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Priority: P1 Type: Bug

Describe the bug

When more than one loaded policy allows the same image, the policy applied to a create is effectively random. GetByImage returns the first policy whose prefixes match while iterating a map: Go map and Rust HashMap iteration order is randomized, so the choice can change from one request to the next; TypeScript's Map keeps load order, so the first-loaded policy always wins. The selected policy decides the forced container_config.user, the volume whitelist and the flag rules, so a container can be created with another service's settings.

This is a normal layout, not an edge case: services built from one image need different policies. Lodestar's beacon node and validator client both run chainsafe/lodestar with different users and data directories, so in a one-trust-domain deployment (README "Trust model") validator creates intermittently get the beacon policy — forced to the beacon user and refused their own data directory.

Affected implementation(s)

  • Go
  • Rust
  • TypeScript
  • All

To Reproduce

  1. Two policies in one --config-dir: 
    # a.yaml
service_name: svc-a
allowed_image_prefixes: [alpine]
container_config: { user: "1111:1111" }
# b.yaml
service_name: svc-b
allowed_image_prefixes: [alpine]
container_config: { user: "2222:2222" }
  2. Through the proxy, docker create alpine:3.20 true six times, restart the proxy, repeat (three runs).
  3. Forced users observed (Go v0.3.11): 
    run 1: 1111 1111 1111 1111 1111 1111
run 2: 1111 2222 1111 1111 1111 1111
run 3: 1111 1111 1111 1111 1111 1111

Expected behavior

Policy selection is deterministic, and services that share an image can be told apart.

Proposed:

  1. Optional container_names in a policy (e.g. container_names: [beacon]). On POST /containers/create, select the policy whose image prefixes match and whose container_names contains the request's ?name=. A policy without container_names matches any name, as today.
  2. Exactly one match, otherwise deny. Zero matches → 403 as today; more than one → 403 with an ambiguity error naming the matching policies. Validate at load time too: two policies that could both match the same image and name should fail startup.

The name is chosen by the caller, so this is routing, not access control — consistent with the trust model, where every caller of a socket already holds the union of its policies.

Environment

  • OS: Ubuntu 22.04.5
  • Docker version: Engine 29.9.0 (API 1.56)
  • Implementation version/commit: v0.3.11 (3130b0a), Go binary

Additional context

Needed by ChainSafe/lodestar-infrastructure's deployment of this proxy (beacon and validator from one image). The Quint model would need the container name as an input to state "the applied policy is the unique match for (image, name)".

Lingua principale
Rust
Stelle
2
Fork
0
Merge medio
12h 11m
PR unite (30g)
30

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ChainSafe/docker-socket-policy

Tutte le issue di ChainSafe/docker-socket-policy

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.