Podemos dizer que toda uma "série" de arquivos em um processo (como representado respectivamente por descritores de arquivo) reflete diretamente esse processo e possíveis subprocessos dele, de modo que, ao examinar os arquivos, descritos pelo arquivo descritores, poderia nos dizer a natureza exata do processo e possíveis subprocessos?
Em outras palavras, se você olhar para cada arquivo (representado por descritores de arquivo em uma ordem respectiva como 0-X), ele informará a natureza do processo e / ou subprocessos? / p>
Eu acredito que a resposta seria sim, se de fato, todo o processo é realmente feito apenas desses arquivos.
Contra-exemplo: Escreva dois programas que durmam por, digamos, 100 segundos, e depois escreva 1 resp. 2 para stderr. Comece ambos do mesmo shell e coloque-os no fundo. Você não será capaz de distingui-los olhando os descritores de arquivos, que são idênticos para ambos.
Variante: faça com que eles abram o mesmo arquivo, para que ele nem funcione se não estiver restrito aos descritores padrão.
Eu não acho que entendo completamente o que você está pedindo ... Por favor, adicione algumas explicações.
Mas pelo que acho que entendo, não .
Uma analogia poderia ser:
If I watch Person A and see who they talk to, can I determine the intent of Person A?
Neste caso, essa resposta é bastante obscura. Você pode ver que a Pessoa A fala com alguma pessoa importante na aplicação da lei, e talvez algumas pessoas associadas ao crime organizado. Mas será extremamente difícil (impossível?) Afirmar com certeza os motivos da Pessoa A. Eles são um policial disfarçado ou um criminoso com um juiz sob o polegar?
Você não pode ler nada com segurança apenas com esse conhecimento.
Se você conseguiu obter mais informações, como a E / S que está sendo realizada, então você está no caminho certo para entender a situação com mais clareza.
In other words, if you look at each file (represented by file descriptors in a respective order like 0-X), will it tell you the nature of the process and or subprocesses?
Eu acho que você está um pouco confuso sobre o que é um ' descritor de arquivo '. Um descritor de arquivo é identificado por um número simples ( int ) - o valor de retorno de open() ... mas dentro do kernel um descritor de arquivo possui informações associadas a ele. Veja struct file .
I believe the answer would be yes, if indeed, the whole process is really made out only of these files.
Isso também contém algumas evidências de falta de compreensão. Um processo não é "feito de apenas estes arquivos", mas ao invés disso está acessando esses arquivos agora mesmo. Podemos mostrar isso executando o seguinte:
$ 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 apontou em um comentário, open() retornará o próximo descritor de arquivo livre, preenchendo quaisquer lacunas de zero. O que você vê acima é um instantâneo dos arquivos que estão abertos no momento e mudará com o tempo.
Você não pode ver o binário ls na lista acima ou qualquer uma de suas dependências imediatas:
$ 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)
Quando você tenta " executar ls " o linker é realmente o que lê os arquivos da biblioteca para agrupar e 'link' a imagem completa do processo. No momento em que ls começa a executar, esses dados já estão na memória e os arquivos não estão mais 'abertos'.
Alguns aplicativos podem usar 'plugins' ou 'dinamicamente' carregar arquivos adicionais que fornecem funcionalidade (veja dlopen() ), mas esse é um caso extremo e está longe de ser um comportamento típico - nenhum dos processos atualmente em execução na minha máquina tem um arquivo de Objeto Compartilhado ( *.so ) aberto.
Em resumo, e ainda de acordo com a minha resposta original, Não .
Não há uma maneira definitiva de determinar o comportamento de um processo, analisando quais arquivos ele abriu.
Em relação à determinação da natureza de um subprocesso, isso é impossível - você pode olhar para init e determinar a configuração completa do tempo de execução de um sistema? Não .
Não.
A maioria dos processos tem um comportamento de descritor muito semelhante. Por exemplo, quase todos os daemons gravam sua saída em logs (arquivos), que geralmente são compartilhados. Por exemplo, no meu sistema, /var/log/journal tem entradas de systemd , gnome-keyring-* , dbus-daemon e muitos outros programas.
Um padrão que é frequentemente usado é redirecionar descritores para / de /dev/{null,zero,urandom,tty*} ou fechá-los.
Outro exemplo - cmp e diff fazem basicamente o mesmo, mas lidam com diferentes tipos de dados.
Existem até mesmo programas no pacote moreutils (que é brilhante) que envolvem alguns padrões comuns de descritores:
chronic - executa um comando silenciosamente, a menos que ele falhe sponge - absorva a entrada padrão e grave em um arquivo (o arquivo é aberto após a entrada é encharcada, então grep "mom" somefile | sponge somefile deixa apenas as linhas em algum arquivo que contém "mom") diff ) E imagine como os descritores estão mudando rapidamente para os programas top ou find . Você precisaria rastreá-los durante todo o tempo de execução.
Uma pergunta para levar para casa: qual é a diferença entre os descritores entre o LibreOffice Writer e o GIMP, ou melhor, sed e WannaCry?
Resposta curta: Sim, mas de uma forma muito limitada.
De fato, observar o que um processo faz é uma das principais funções de um antivírus, como entre os arquivos que são abertos também são os de DLLs (Windows) ou bibliotecas compartilhadas (Linux). Um antivírus que julgue o comportamento de um processo irá disparar o alarme quando um processo abre arquivos demais ou muito sensíveis, ou tenta acessar pastas sensíveis. O Windows / Linux pode solicitar permissão de usuário em tais casos.
É possível detectar que um processo está abrindo uma DLL / biblioteca compartilhada, mas descobrir quais APIs ele chama requer a análise do sistema chama isso, o que um antivírus pode encontrar examinando o executável próprio arquivo do processo.
Não esqueça que o próprio executável é um dos arquivos abertos, para que sua análise possa dizer exatamente quais DLLs / shared-libraries ele usa, que pode dar uma boa compreensão do que faz.
O SO irá observar o comportamento do processo e irá classificá-lo em um agendamento de classe como um limite de CPU ou IO-bound ou misto, o que afetará sua prioridade de execução e suas fatias permitidas de recursos do sistema.
Um subprocesso geralmente herdará todos os descritores de arquivo abertos de seus pai, e, portanto, vai começar a sua vida na mesma classificação aos olhos do sistema operacional e antivírus, mas pode, mais tarde, através de suas ações, passar para outra classificação.
Tags process file-descriptors