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

fd://3 socket activation: not verified to be listening, and sd_listen_fds env contract unchecked in all three

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

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

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

Línea de trabajo

Comienza con la ruta de dispatch de Rust para fd://3 y su helper de fd-wrapping; después compara el manejo existente en Go en go/main.go:78. Ejecuta o añade la prueba de subprocess propuesta, que hace dup2 de un listener real sobre fd 3 y ejercita la ruta de extremo a extremo. La tarea estará completa cuando un fd no válido falle rápidamente durante el arranque con un error claro, mientras que un socket AF_UNIX válido en escucha siga funcionando.

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

Descripción

Priority: P3 Type: Enhancement

Partially resolved (2026-09-28) by a40a07f (#41, carrying #35's work). The socket family is now checked; "is it listening" and the sd_listen_fds env contract are not. Scope narrowed below.

Summary

With --listen-socket=fd://3, the Rust implementation adopts fd 3 via from_raw_fd without verifying it is actually a listening AF_UNIX socket. Go's net.FileListener (go/main.go:78) rejects non-socket fds; Rust only surfaces the problem later as io::Error from set_nonblocking/accept (mitigated by the accept-error backoff added in #27 — no busy loop, but also no clear early failure).

Neither implementation checks the LISTEN_PID/LISTEN_FDS environment variables from the sd_listen_fds convention, so this is parity-plus hardening.

Affected implementation(s)

  • Rust — family check done; SO_ACCEPTCONN and LISTEN_FDS outstanding
  • Go — family check done; LISTEN_PID/LISTEN_FDS outstanding
  • TypeScript — family check done; LISTEN_PID/LISTEN_FDS outstanding

What has landed

unix_listener_from_raw_fd (rs/src/main.rs) now calls local_addr() immediately after from_raw_fd and rejects the fd if it is not AF_UNIX:

fd 3 is not a Unix socket (...): set ListenStream to a filesystem path in the .socket unit

Covered by test_unix_listener_from_raw_fd_rejects_tcp_socket. Go got the equivalent guard (listenerFromFile rejects a non-*net.UnixListener), and TypeScript checks server.address() is a string. So the original cross-language gap — a unit with ListenStream=127.0.0.1:2375 silently reinstating a TCP listener — is closed in all three.

What remains

  1. Not verified to be listening. An AF_UNIX socket that was never listen(2)ed still passes. getsockopt(SOL_SOCKET, SO_ACCEPTCONN) would catch it. Currently degrades to accept errors at runtime (rate-limited by the backoff from #27, so no busy loop, but no clear startup failure either).
  2. sd_listen_fds contract unchecked in all three. No implementation validates LISTEN_PID == getpid() or LISTEN_FDS >= 1. Without the LISTEN_PID check the process will happily adopt an inherited fd 3 that systemd never intended for it.
  3. No end-to-end test of the fd://3 dispatch path. Only the fd-wrapping helper is unit-tested; a subprocess test that dup2s a real listener onto fd 3 would cover the actual branch.

Expected behavior

--listen-socket=fd://3 with an fd that is not a listening AF_UNIX socket should fail fast at startup with a clear error, not degrade into accept errors at runtime.

Suggested fix

The fstat/S_IFSOCK step is effectively covered by the family check already in place. Remaining:

  • getsockopt(SOL_SOCKET, SO_ACCEPTCONN) to confirm the fd is listening
  • validate LISTEN_PID == getpid() and LISTEN_FDS >= 1 per the sd_listen_fds convention — in all three, for parity
  • a subprocess test that dup2s a real listener onto fd 3 and exercises the fd://3 dispatch path end-to-end

Context

Split out from the review follow-ups on PR #27. Related: #25, #28 (both now closed).

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.