Início / unix / Perguntas / 700067
Accepted
Daniel Walker
Asked: 2022-04-23 19:40:56 +0800 CST

O que significam as permissões em /proc/<pid>/fd/?

  • 772

Estou olhando para o resultado da execução ls -lem /proc/<pid>/fd/:

lr-x------ 1 root root 64 Apr 22 23:13 0 -> /dev/null
lrwx------ 1 root root 64 Apr 22 23:13 1 -> 'socket:[19700]'
lrwx------ 1 root root 64 Apr 22 23:13 2 -> 'socket:[19700]'
...

O que significam as permissões nos links simbólicos? A primeira coisa que me ocorre é que eles representam o "modo" dos descritores de arquivo. No entanto, se esse for realmente o caso, por que seria stdoutlegível? Além disso, por que todos os descritores seriam executáveis?

permissions symlink

2 respostas

  1. man chmod(1) disse:

    chmod nunca altera as permissões de links simbólicos; a chamada de sistema chmod não pode alterar suas permissões. Isso não é um problema, pois as permissões de links simbólicos nunca são usadas. No entanto, para cada link simbólico listado na linha de comando, chmod altera as permissões do arquivo apontado.

    Eles basicamente não significam nada.

    • 2
  2. Best Answer

    O sistema de arquivos do Linux /procapresenta objetos que na verdade não são arquivos como arquivos: está usando uma API conhecida para apresentar objetos como arquivos.

    Para os descritores de arquivo, não existe um link simbólico real. Mas um link simbólico é uma maneira conveniente de apresentar informações sobre o descritor de arquivo. Esse link simbólico é criado dinamicamente quando necessário (e pode possivelmente ficar armazenado em cache no VFS para que geralmente tenha a data da primeira vez em que foi exibido). Normalmente, no Linux, os links simbólicos estão sempre tendo todos os direitos permitidos possíveis, porque é o destino deles que é validado. Mas aqui, os direitos são apresentados para refletir a forma como o descritor de arquivo foi aberto. Eles são apresentados como pertencentes ao usuário (ou às vezes root quando, por exemplo, o processo é definido como não descartável ou não rastreável) e limitados aos atributos de acesso do usuário, mesmo que os atributos de acesso não sejam realmente verificados (a verificação de propriedade é aplicada, Veja abaixo). Muitos detalhes estão documentados emproc(5)na /proc/[pid]/fd/entrada, por exemplo:

    /proc/[pid]/fd/

    [...]

    Para descritores de arquivo para pipes e sockets, as entradas serão links simbólicos cujo conteúdo é o tipo de arquivo com o inode. Uma chamada readlink(2) neste arquivo retorna uma string no formato:

    tipo:[inode]

    [...]

    A permissão para desreferenciar ou ler (readlink(2)) os links simbólicos neste diretório é governada por uma PTRACE_MODE_READ_FSCREDSverificação do modo de acesso ptrace; veja ptrace(2).

    para que se possa verificar apenas os processos pertencentes ao mesmo usuário (ou nem mesmo, se o processo estiver definido como não descartável/não rastreável e outras ressalvas especiais).

    O que não consegui encontrar documentado proc(5)é que geralmente os direitos de acesso apresentados nos links simbólicos proc/[pid]/fd/refletem a maneira como o descritor de arquivo foi aberto. Portanto, abrir somente leitura ( ls -l /proc/self/fd/9 9</dev/null), somente gravação ( ls -l /proc/self/fd/9 9>/dev/null) ou leitura-gravação ( ls -l /proc/self/fd/9 9<>/dev/null) serão exibidos respectivamente com estes direitos de acesso:

    lr-x------
l-wx------
lrwx------

    Da mesma forma, pipes (sem nome) criados com pipe(2)terão um FD no modo de leitura e um no modo de gravação. Os soquetes são bidirecionais: não há noção de "abri-los" somente leitura ou somente gravação, na verdade nunca há uma open(2)chamada de sistema para eles. Eles serão vistos como lrwx------para refletir que podem ser lidos ou escritos.

    • 2

relate perguntas