¿Es seguro analizar un archivo / proc/?

Aunque los archivos en /proc aparecen como archivos regulares en el espacio de usuario, no son realmente archivos, sino entidades que soportan las operaciones de archivos estándar desde el espacio de usuario (open, read, close). Tenga en cuenta que esto es bastante diferente a tener un archivo ordinario en el disco que está siendo cambiado por el núcleo.

Todo lo que hace el núcleo es imprimir su estado interno en su propia memoria usando una función similar a sprintf, y esa memoria se copia en el espacio de usuario cada vez que emite un read(2) llamada al sistema.

El núcleo maneja estas llamadas de una manera completamente diferente que para los archivos normales, lo que podría significar que toda la instantánea de los datos que leerá podría estar lista en el momento en que lo open(2), mientras que el núcleo se asegura de que las llamadas simultáneas sean consistentes y atómicas. No lo he leído en ninguna parte, pero no tiene sentido ser de otra manera.

Mi consejo es echar un vistazo a la implementación de un archivo proc en su sabor Unix particular. Esto es realmente un problema de implementación (al igual que el formato y el contenido de la salida) que no se rige por un estándar.

El ejemplo más simple sería la implementación de la uptime archivo proc en Linux. Observe cómo se produce todo el búfer en la función de devolución de llamada suministrada a single_open.

/proc es un sistema de archivos virtual : de hecho, solo proporciona una vista conveniente de las funciones internas del núcleo. Definitivamente es seguro leerlo (por eso está aquí), pero es arriesgado a largo plazo, ya que el interno de estos archivos virtuales puede evolucionar con una versión más reciente del kernel.

EDITAR

Más información disponible en documentación proc en Linux kernel doc , capítulo 1.4 Redes No puedo encontrar si la información cómo la información evoluciona con el tiempo. Pensé que se congeló en abierto, pero no puede tener una respuesta definitiva.

EDIT2

De acuerdo con Sco doc (no linux, pero estoy bastante seguro de que todos los sabores de *nix se comportan así)

Aunque el estado del proceso y en consecuencia, el contenido de / proc los archivos pueden cambiar de instante a instantánea, una sola lectura (2) de a / proc el archivo está garantizado para devolver un representación "sana" del Estado, que es, la lectura será una atómica instantánea del estado de la proceso. Dicha garantía no se aplica a lecturas sucesivas aplicadas a a / proc archivo para un proceso en ejecución. En además, la atomicidad es específicamente no se garantiza ninguna E / S aplicada a el archivo as (espacio de direcciones); el contenido de la dirección de cualquier proceso el espacio puede modificarse simultáneamente por un LWP de ese proceso o cualquier otro proceso en el sistema.

La API procfs en el núcleo Linux proporciona una interfaz para asegurarse de que las lecturas devuelven datos consistentes. Lea los comentarios en __proc_file_read. Item 1) en el bloque de comentarios grandes explica esta interfaz.

Dicho esto, por supuesto depende de la implementación de un archivo proc específico usar esta interfaz correctamente para asegurarse de que sus datos devueltos sean consistentes. Por lo tanto, para responder a su pregunta: no, el núcleo no garantiza la consistencia de los archivos proc durante una lectura, pero proporciona los medios para que las implementaciones de esos archivos proporcionen consistencia.

Tengo a mano el código fuente para Linux 2.6.27.8 ya que estoy desarrollando controladores en este momento en un destino ARM incrustado.

El archivo ...linux-2.6.27.8-lpc32xx/net/ipv4/raw.c en la línea 934 contiene, por ejemplo

    seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
            " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d\n",
            i, src, srcp, dest, destp, sp->sk_state,
            atomic_read(&sp->sk_wmem_alloc),
            atomic_read(&sp->sk_rmem_alloc),
            0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
            atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));

Que produce

[wally@zenetfedora ~]$ cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 15160 1 f552de00 299
   1: 00000000:C775 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 13237 1 f552ca00 299
...

In function raw_sock_seq_show()que forma parte de una jerarquía de procfs funciones de manejo. El texto no se genera hasta que se hace una solicitud read() del archivo /proc/net/tcp, un mecanismo razonable ya que procfs las lecturas son seguramente mucho menos comunes que actualización de la información.

Algunos controladores (como el mío) implementan la función proc_read con un solo sprintf(). La complicación adicional en la implementación de los controladores principales es manejar una salida potencialmente muy larga que puede no caber en el búfer intermedio del espacio del núcleo durante una sola lectura.

Lo probé con un programa que usa un búfer de lectura de 64K, pero resulta en un búfer de espacio del núcleo de 3072 bytes en mi sistema para que proc_read devuelva los datos. Múltiples llamadas con avance se necesitan punteros para obtener más que esa cantidad de texto devuelto. No se cuál es la manera correcta de hacer que los datos devueltos sean consistentes cuando se necesita más de una e/s. Ciertamente cada entrada en /proc/net/tcp es auto-consistente. Existe cierta probabilidad de que las líneas de lado a lado sean instantáneas en diferentes momentos.

A excepción de errores desconocidos, no hay condiciones de carrera en /proc que llevarían a la lectura de datos dañados o una mezcla de datos antiguos y nuevos. En este sentido, es seguro. Sin embargo, todavía existe la condición de carrera de que gran parte de los datos que se leen de /proc es potencialmente obsoleta tan pronto como se genera, e incluso más para el momento en que se llega a la lectura/procesamiento de la misma. Por ejemplo, los procesos pueden morir en cualquier momento y a un nuevo proceso se le puede asignar el mismo pid; los únicos ID de proceso que puede usar sin las condiciones de carrera son tus propios procesos hijos. Lo mismo ocurre con la información de la red (puertos abiertos, etc.) y realmente la mayor parte de la información en /proc. Consideraría una práctica mala y peligrosa confiar en que cualquier dato en /proc sea preciso, excepto los datos sobre su propio proceso y potencialmente sus procesos hijos. Por supuesto, todavía puede ser útil presentar otra información de /proc al usuario / administrador para información / registro / etc. propósito.

Cuando lee desde un archivo /proc, el núcleo está llamando a una función que ha sido registrada de antemano para ser la función "read" para ese archivo proc. Vea la función __proc_file_read en fs/proc/generic.c.

Por lo tanto, la seguridad del proc read es tan segura como la función que el núcleo llama para satisfacer la solicitud de lectura. Si esa función bloquea correctamente todos los datos que toca y te devuelve en un búfer, entonces es completamente seguro leer usando esa función. Desde archivos proc como el que se utiliza para satisfacer las solicitudes de lectura a/proc/net / tcp ha existido por un tiempo y ha sido objeto de una revisión escrupulosa, son casi tan seguros como podría pedir. De hecho, muchas utilidades comunes de Linux se basan en leer desde el sistema de archivos proc y formatear la salida de una manera diferente. (En la parte superior de mi cabeza, creo que ' ps ' y 'netstat' hacen esto).

Como siempre, no tienes que creer en mi palabra; puedes mirar la fuente para calmar tus miedos. La siguiente documentación de proc_net_tcp.txt le indica dónde funcionan las funciones de" lectura " de /proc/net/tcp, para que pueda ver el código real que se ejecuta cuando lee ese archivo proc y verificar por sí mismo que no hay riesgos de bloqueo.

Este documento describe las interfaces /proc/net/tcp y /proc/net/tcp6.
Tenga en cuenta que estas interfaces son obsoleto a favor de tcp_diag. Estas interfaces / proc proporcionan información sobre TCP actualmente activo conexiones, y son ejecutadas por tcp4_seq_show () en net / ipv4 / tcp_ipv4.c y tcp6_seq_show() en net / ipv6 / tcp_ipv6.c, respectivamente.