capability.LastCap fails when /proc/sys/kernel/cap_last_cap is unavailable
Nadie ha tomado este issue todavía.
- #266 de @sairex53 — cerrado sin fusionar
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 50/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Activo
- Stack tecnológico
- go, linux
- Área
- operating-systems, security
Línea de trabajo
Start with the LastCap function in the capability package and the ListSupported path that calls it, both of which read /proc/sys/kernel/cap_last_cap directly. Check how the error propagates, then find a way to determine the last capability without that file, such as probing with prctl. Done means LastCap no longer fails when the file is absent, with a test that simulates the missing file.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
capability.LastCap() returns an error when /proc/sys/kernel/cap_last_cap is unavailable. This can cause callers to fail after entering a rootfs that does not contain a /proc mount.
I encountered this through runc 1.3.4. With an OCI configuration containing mounts: [] and five explicitly empty capability sets, runc create failed 5/5 times with:
open /proc/sys/kernel/cap_last_cap: no such file or directory
The workload was /bin/true, so it did not access /proc. Adding only a private /proc mount made runc succeed 5/5 times. crun and youki accepted the original configuration.
It appears that ListSupported() calls LastCap(), which directly opens /proc/sys/kernel/cap_last_cap and returns the error without a fallback.
I expected capability handling, especially for empty capability sets, not to require this file to exist inside the current rootfs.
Original runc report and full reproducer:
https://github.com/opencontainers/runc/issues/5551
- Lenguaje dominante
- Go
- Estrellas
- 102
- Forks
- 62
- Merge medio
- 6 min
- PR fusionados (30 d)
- 2
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de moby/sys
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
devices: ignore .incus-mounts in GetDevicesPosiblemente ocupada @SashaMIT la tomó hace 10 días. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
-
[userns-remap] Bug: ToHost incorrectly maps non-root container UID to root when it collides with RootPairPosiblemente ocupada @okhowang la tomó hace 76 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 74/100
-
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Issues similares
-
Dificultad 2/5 Menos de una hora Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día
-
[Low] CSI plugin builds staging directories from storage_volume_id without a containment checkAbiertoarea/security kind/bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
agent-substrate/substrate#2935 ·
Los mantenedores suelen responder en 1 día
-
100 points complexity: trivial documentation drips-wave good first issue help wanted
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
Los mantenedores suelen responder en 1 día
-
automation models
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Guardian health server binds :8080 and collides with the Voltron proxyPosiblemente ocupada @denislemire la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
projectcalico/calico#14341 ·
Los mantenedores suelen responder en 1 día