Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Cerrado
  • ¿Algo no está bien?
#85 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Ya se ha fusionado un pull request relacionado.

  • #90 de @abienkowski — fusionado

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
18/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
docker, go, rust, typescript
Área
api, security

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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)".

Lenguaje dominante
Rust
Estrellas
2
Forks
0
Merge medio
12 h 11 min
PR fusionados (30 d)
30

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ChainSafe/docker-socket-policy

Todos los issues de ChainSafe/docker-socket-policy

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.