¿Podemos decir que los procesos (con o sin subprocesos) se reflejan totalmente en sus archivos (descriptivos)?

¿Podemos decir que una "serie" completa de archivos en un proceso (como se representa respectivamente por los descriptores de archivo) refleja directamente este proceso y los posibles subprocesos del mismo, de modo que al examinar los archivos, descritos por los descriptores de archivo, podría ¿Cuéntanos la naturaleza exacta del proceso y los posibles subprocesos?

En otras palabras, si observa cada archivo (representado por descriptores de archivo en un orden respectivo como 0-X), ¿le dirá la naturaleza del proceso o subprocesos?

Creo que la respuesta sería sí, si de hecho, todo el proceso realmente está hecho solo de estos archivos.

Respuesta corta: no

Respuesta larga: los descriptores de archivo utilizados por un proceso no son lo suficientemente estáticos como para permitir un análisis confiable del proceso. Los archivos se pueden abrir y cerrar, las estructuras de datos correspondientes serán recicladas por el núcleo.

Contraejemplo: escriba dos programas que duerman durante, por ejemplo, 100 segundos, y luego escriba 1 resp. 2 a stderr. Comience ambos desde el mismo caparazón y póngalos en segundo plano. No podrá distinguirlos mirando los descriptores de archivo, que son idénticos para ambos.

Variante: haga que abran el mismo archivo, por lo que ni siquiera funciona si no está restringido a los descriptores estándar.

No creo entender completamente lo que está preguntando ... Agregue alguna explicación.

Pero por lo que creo que entiendo, no .

Una analogía podría ser:

Si miro a la Persona A y veo con quién hablan, ¿puedo determinar la intención de la Persona A?

En este caso, esa respuesta es bastante turbia. Es posible que pueda ver que la Persona A habla con alguna persona importante en la aplicación de la ley, y tal vez con algunas personas asociadas con el crimen organizado. Pero va a ser extremadamente difícil (¿imposible?) Declarar con certeza los motivos de la Persona A. ¿Son policías encubiertos o delincuentes con un juez bajo el pulgar?

No se puede leer nada confiablemente en tal conocimiento solo.

Si lograra obtener más información, como la E / S que se está realizando, entonces estaría en camino de comprender la situación con mayor claridad.

En otras palabras, si observa cada archivo (representado por descriptores de archivo en un orden respectivo como 0-X), ¿le dirá la naturaleza del proceso y / o subprocesos?

Creo que estás algo confundido acerca de lo que es un " descriptor de archivo ". Un descriptor de archivo se identifica mediante un número simple ( int): el valor de retorno de open()... pero dentro del núcleo un descriptor de archivo tiene información asociada. Ver struct file.

Creo que la respuesta sería sí, si de hecho, todo el proceso realmente está hecho solo de estos archivos.

Esto también tiene alguna evidencia de mala comprensión. Un proceso no está " hecho solo de estos archivos ", sino que está accediendo a estos archivos en este momento . Podemos mostrar esto ejecutando lo siguiente:

$ ls -l /proc/self/fd
total 0
lrwx------ 1 attie attie 64 May 20 15:20 0 -> /dev/pts/3
lrwx------ 1 attie attie 64 May 20 15:20 1 -> /dev/pts/3
lrwx------ 1 attie attie 64 May 20 15:20 2 -> /dev/pts/3
lr-x------ 1 attie attie 64 May 20 15:20 3 -> /proc/13103/fd

Como @grawity ha señalado en un comentario, open()devolverá el siguiente descriptor de archivo gratuito, llenando los vacíos desde cero. Lo que ves arriba es una instantánea de los archivos que están abiertos actualmente y que cambiarán con el tiempo.

No puede ver el lsbinario en la lista anterior, ni ninguna de sus dependencias inmediatas:

$ ldd $(which ls)
        linux-vdso.so.1 =>  (0x00007fff569ef000)
        libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007feeb33df000)
        libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007feeb31d7000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feeb2e0e000)
        libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007feeb2bd0000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feeb29cc000)
        /lib64/ld-linux-x86-64.so.2 (0x00007feeb361a000)
        libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007feeb27c6000)

Cuando intenta " ejecutarls ", el enlazador es en realidad lo que lee los archivos de la biblioteca para clasificar y "enlazar" la imagen completa del proceso. Cuando lscomienza a ejecutarse, estos datos ya están en la memoria y los archivos ya no están "abiertos".

Algunas aplicaciones pueden hacer uso de 'complementos' o cargar 'dinámicamente' archivos adicionales que brindan funcionalidad (ver dlopen()), pero este es un caso extremo y está lejos del comportamiento típico: ninguno de los procesos que se ejecutan actualmente en mi máquina tiene un objeto compartido ( *.so) archivo abierto.

En resumen, y aún de acuerdo con mi respuesta original, no .

No hay una forma definitiva de determinar el comportamiento de un proceso al observar qué archivos tiene abiertos.

En cuanto a determinar la naturaleza de un subproceso, esto es imposible: ¿puede observar inity determinar la configuración de tiempo de ejecución completa de un sistema? No se .

No.

La mayoría de los procesos tienen un comportamiento descriptor muy similar. Por ejemplo, casi todos los demonios escriben su salida en registros (archivos), que a menudo se comparten. Por ejemplo, en mi sistema /var/log/journaltiene entradas de systemd, gnome-keyring-*, dbus-daemony muchos programas más.

Un patrón que se usa a menudo es redireccionar descriptores hacia / desde /dev/{null,zero,urandom,tty*}, o cerrarlos.

Otro ejemplo, cmpy diffbásicamente hacen lo mismo, pero tratan con diferentes tipos de datos.

Incluso hay programas en el moreutilspaquete (que es brillante) que envuelven algunos patrones de descriptores comunes:

• chronic - ejecuta un comando en silencio a menos que falle
• sponge- absorber la entrada estándar y escribir en un archivo (el archivo se abre después de empapar la entrada, de modo que grep "mom" somefile | sponge somefilesolo deja esas líneas en algún archivo que contienen "mamá")
• combine: combine conjuntos de líneas de dos archivos mediante operaciones booleanas (los mismos descriptores que diff)

E imagine, qué tan rápido están cambiando los descriptores topo los findprogramas. Debería rastrearlos durante todo el tiempo de ejecución.

Una pregunta para llevar a casa: ¿cuál es la diferencia en los descriptores entre LibreOffice Writer y GIMP, o mejor, sedy WannaCry?

Respuesta corta: Sí, pero de manera muy limitada.

De hecho, observar lo que hace un proceso es una de las funciones principales de un antivirus, ya que entre los archivos que se abren también están los de DLL (Windows) o bibliotecas compartidas (Linux). Un antivirus que juzga el comportamiento de un proceso generará la alarma cuando un proceso abra demasiados archivos demasiado confidenciales o intente acceder a carpetas confidenciales. Windows / Linux puede solicitar permiso del usuario en tales casos.

Es posible detectar que un proceso está abriendo un archivo DLL / biblioteca compartida, pero para averiguar qué API llama requiere el análisis de las llamadas del sistema que hace, que un antivirus puede encontrar al examinar el archivo ejecutable del proceso. .

No olvide que el ejecutable en sí es uno de los archivos abiertos, por lo que su análisis puede decir exactamente qué DLL / bibliotecas compartidas usa, lo que puede proporcionar una muy buena comprensión de lo que hace.

El sistema operativo observará el comportamiento del proceso y lo clasificará en una clase de programación como un límite de CPU o de E / S o mixto, lo que afectará su prioridad de ejecución y sus segmentos permitidos de recursos del sistema.

Un subproceso generalmente heredará todos los descriptores de archivo abiertos de su padre y, por lo tanto, comenzará su vida en la misma clasificación a los ojos del sistema operativo y el antivirus, pero más tarde, a través de sus acciones, puede pasar a otra clasificación.