Linux 7.3 estrena failfs: limitar rutas no retira todos los accesos
Índice de contenidos
Claves de la noticia
- Linus Torvalds ha publicado Linux 7.3; su anuncio corresponde a la madrugada del 19 de octubre en España peninsular.
- failfs y fchroot permiten restringir cómo un proceso localiza archivos, pero conservan vías de acceso que el programa debe gestionar.
- Ubuntu 26.10 salió con una base 7.3-rc6: el lanzamiento final del núcleo y la actualización de una distribución son pasos distintos.
Linux 7.3 ya está disponible y añade mecanismos de aislamiento, planificación de procesos y gestión de recursos. Entre sus novedades destaca una idea poco intuitiva: un sistema de archivos que rechaza las operaciones que llegan hasta él puede servir para limitar a un programa. La utilidad depende de cómo se prepare ese programa, y no se activa por el mero hecho de instalar el núcleo.
El anuncio cae el lunes en España
El mensaje original de Torvalds, archivado por LWN, está fechado el domingo 18 a las 13:41:11 con zona −10:00. Convertido a UTC son las 23:41:11; en Madrid, las 01:41:11 del lunes 19. Esa conversión explica por qué una noticia con fecha estadounidense del domingo pertenece a la actualidad tecnológica española de hoy.
Torvalds da por terminada la versión 7.3 y anuncia la apertura de la ventana de integración de 7.4 al día siguiente. También advierte de que sus vacaciones podrían alterar el ritmo de incorporación de cambios. La publicación proporciona una base final sobre la que trabajar; la entrega a cada ordenador sigue dependiendo de su distribución.
Un sistema de archivos que obliga a elegir la entrada
El inventario técnico de Linux 7.3 en Kernel Newbies recoge la combinación de failfs con la nueva llamada fchroot. Esta última permite cambiar la raíz usando un descriptor de archivo: una referencia que el proceso ya tiene abierta. Evita volver a resolver por nombre un destino que ya estaba identificado, así como la carrera entre esa búsqueda y el cambio de raíz.
La documentación de failfs para 7.3 precisa su comportamiento: las operaciones que llegan a este sistema interno reciben EOPNOTSUPP, el error de operación no admitida. No se monta desde el espacio de usuario ni permite colocar otro montaje encima. Su función es cerrar determinadas formas de recorrer el árbol de archivos.
Importa distinguir dos referencias: la raíz y el directorio de trabajo. Situar la raíz en failfs hace fallar las búsquedas absolutas; situar allí el directorio de trabajo bloquea las búsquedas relativas a ese directorio. Las búsquedas ancladas en descriptores explícitos de directorio siguen funcionando. De esa combinación sale una consecuencia práctica: restringir las rutas no revoca las referencias ya entregadas al proceso.
| Punto de partida | Resultado documentado |
|---|---|
| Ruta absoluta | Falla al recorrer failfs |
| Directorio de trabajo | Falla la búsqueda relativa |
| Descriptor explícito de directorio | La búsqueda puede continuar |
La tabla permite leer el cambio como una selección de entradas autorizadas. Un desarrollador puede preparar las referencias necesarias antes de restringir el entorno; si conserva referencias demasiado amplias, conserva también acceso que quizá pretendía retirar. Es una conclusión sobre el diseño documentado, no el resultado de una prueba de intrusión propia.
La aplicación también tiene que cambiar
La misma documentación advierte de otro límite: resolver el intérprete de un ejecutable enlazado dinámicamente requiere una ruta absoluta. Con la raíz en failfs, esa operación falla. Por eso no basta con envolver cualquier programa existente y esperar que continúe funcionando: hay que conocer sus dependencias de acceso y cuándo necesita resolverlas.
Para quien desarrolla servicios o herramientas de procesamiento de archivos, el trabajo concreto consiste en identificar qué directorios necesita cada tarea y qué referencias hereda. La novedad ofrece una pieza para construir ese aislamiento. No demuestra que una aplicación la haya integrado ni permite atribuir protección automática a todo el software que se ejecute sobre 7.3.
Distintas cargas pueden tener distintos planificadores
La versión también completa el soporte de subplanificadores de sched_ext por cgroup. Los cgroups agrupan procesos para gestionar recursos; con este mecanismo, distintos grupos pueden utilizar planificadores basados en BPF y tomar decisiones diferentes. Es relevante cuando conviven cargas con necesidades distintas en una misma máquina.
La documentación de sched_ext explica que la política puede implementarse mediante programas BPF y que el sistema dispone de mecanismos para volver al planificador normal ante errores. Esa flexibilidad exige una política y una configuración concretas: la presencia de la infraestructura no demuestra una mejora de rendimiento en cualquier aplicación.
En un servidor que comparte trabajos interactivos y procesamiento por lotes, la pregunta útil es qué comportamiento necesita cada grupo y cómo se medirá. No hay una cifra universal de aceleración que pueda trasladarse a todos los equipos. La separación entre función disponible, activación y resultado medido también importa al valorar cambios en plataformas de virtualización.
Ubuntu ya decía 7.3 antes de la versión final
Las notas oficiales de Ubuntu 26.10 documentan que el núcleo de sus imágenes de lanzamiento, identificado como 7.3.0-9.9, está basado en 7.3-rc6. La explicación es temporal: la versión final de upstream estaba prevista después de la disponibilidad general de Ubuntu. Ya detallamos esa base en la noticia del lanzamiento de Ubuntu 26.10.
Comparar ambos documentos evita confundir una etiqueta de paquete con su punto de partida. El anuncio de Torvalds de hoy no cambia por sí mismo las imágenes publicadas el 15 ni acredita que un equipo haya recibido otro paquete. Para saber qué ejecuta una instalación hay que consultar su versión instalada y la información de actualización de su distribución.
La conclusión para administradores y usuarios es concreta: Linux 7.3 final ya existe, pero su disponibilidad no equivale a adopción ni a activación de sus funciones. failfs requiere preparar el acceso de la aplicación; sched_ext necesita una política de planificación; y la distribución decide qué núcleo entrega. Son tres comprobaciones diferentes antes de atribuir a un equipo las novedades del lanzamiento.
Imagen: escena conceptual generada con IA; no representa una prueba de Linux 7.3.




