Início / unix / Perguntas / 791390
Accepted
codeandfire
Asked: 2025-02-21 16:16:46 +0800 CST

Por que alguns links simbólicos são ilegíveis quando seu destino é legível?

  • 772

No Linux, estou olhando para /proc/1/cwd. Este symlink não é legível como um usuário normal:

$ ls /proc/1/cwd
ls: cannot access '/proc/1/cwd': Permission denied

Mas /proc/1é acessível:

$ ls /proc/1
<output>

Depois de se tornar root, você verá que /proc/1/cwdaponta para /(raiz do sistema de arquivos):

$ sudo ls -l /proc/1/cwd
lrwxrwxrwx 1 root root 0 Feb 21 12:56 /proc/1/cwd -> /

E é claro que a raiz do sistema de arquivos é legível, como um usuário normal:

$ ls /
<output>

Se links simbólicos não têm permissões no Linux, então por que um link simbólico não é legível, quando seu destino (a raiz do sistema de arquivos) é legível?

linux

2 respostas

  1. Best Answer

    Ler /normalmente não é privilegiado, mas conhecer o diretório de trabalho atual dos processos de outro usuário é. /procadiciona verificações adicionais antes de permitirreadlink :

    A permissão para desreferenciar ou ler ( readlink(2)) este link simbólico é regida por uma verificação ptracede modo de acesso PTRACE_MODE_READ_FSCREDS; consulte ptrace(2).

    Isso se aplica a outros links dentro de /proc, em particular exee root. O raciocínio é similar: o executável de um processo é tipicamente legível por todos, mas saber o executável de um dado processo é uma informação sensível.

    • 5

  2. Esse é o diretório de trabalho atual do processo, que é considerado privado e possivelmente sensível.

    Ver man 5 proc_pid_cwd:

    A permissão para desreferenciar ou ler ( readlink(2)) este link simbólico é governado por uma verificação do modo de acesso ptrace PTRACE_MODE_READ_FSCREDS; veja ptrace(2)

    Com [ man 2 ptrace] tendo:

    Verificação do modo de acesso Ptrace

    Várias partes da API do kernel-user-space (não apenas ptrace() operações) exigem as chamadas verificações de "modo de acesso ptrace", cujo resultado determina se uma operação é permitida (ou, em alguns casos, faz com que uma operação de "leitura" retorne dados higienizados). Essas verificações são realizadas em casos em que um processo pode inspecionar informações confidenciais sobre, ou em alguns casos modificar o estado de, outro processo. As verificações são baseadas em fatores como as credenciais e capacidades dos dois processos, se o processo "alvo" é ou não dumpável e os resultados das verificações realizadas por qualquer Linux Security Module (LSM) habilitado — por exemplo, SELinux, Yama ou Smack — e pelo commoncap LSM (que é sempre invocado).

    Antes do Linux 2.6.27, todas as verificações de acesso eram de um único tipo. Desde o Linux 2.6.27, dois níveis de modo de acesso são distinguidos:

    PTRACE_MODE_READ

    Para operações de "leitura" ou outras operações menos perigosas, como: get_robust_list(2); kcmp(2); leitura /proc/pid/auxv, /proc/pid/environ, ou /proc/pid/stat; ou readlink(2) de um /proc/pid/ns/*arquivo.
    [...]

    PTRACE_MODE_FSCREDS

    Use o UID e o GID do sistema de arquivos do chamador (consulte credentials(7) ) ou recursos efetivos para verificações de LSM.
    [...]
    Como a combinação de um dos modificadores de credenciais com um dos modos de acesso mencionados acima é típica, algumas macros são definidas nas fontes do kernel para as combinações:

    PTRACE_MODE_READ_FSCREDS

    Definido como PTRACE_MODE_READ | PTRACE_MODE_FSCREDS.

    E man 7 credentialstendo:

    • ID do usuário do sistema de arquivos e ID do grupo do sistema de arquivos (específico do Linux). Esses IDs, em conjunto com os IDs de grupo suplementares descritos abaixo, são usados ​​para determinar permissões para acessar arquivos; veja path_resolution(7) para detalhes. Sempre que o ID efetivo do usuário (grupo) de um processo é alterado, o kernel também altera automaticamente o ID do usuário (grupo) do sistema de arquivos para o mesmo valor. Consequentemente, os IDs do sistema de arquivos normalmente têm os mesmos valores que o ID efetivo correspondente, e a semântica para verificações de permissão de arquivo é, portanto, a mesma no Linux como em outros sistemas UNIX. Os IDs do sistema de arquivos podem ser feitos para diferir dos IDs efetivos chamando setfsuid(2) e setfsgid(2).

    (essencialmente o mesmo que IDs efetivos , aqueles IDs de FS específicos do Linux estão sendo descontinuados por não serem mais necessários, de acordo com a setfsgid()página de manual do ).

    Então, basicamente, para poder fazer um readlink()ou desreferenciar /proc/$pid/cwd, o processo de chamada (se não estiver relacionado a $pid) deve ter as mesmas credenciais que as de $pid. Observe que ele verifica os IDs do sistema de arquivos do processo de chamada (efetivos) em relação a todos os IDs efetivos, reais e salvos de$pid . Então, se isso $pidtiver gid efetivo e real diferentes, por exemplo (como quando um processo executa um arquivo que tem o bit sgid definido em suas permissões), somente root(ou um processo com capacidades apropriadas) pode obter essas informações.

    No caso do pid 1, normalmente executado como roote que não tem pai, só rootpode obter essa informação.

    Como observação lateral, observe que lsse comporta de forma diferente com e sem -l.

    Com -l(ou algumas outras opções que relatam alguns atributos do arquivo de destino, como -F), lsele faz um lstat()no arquivo e, portanto, para um link simbólico, ele retorna informações sobre o próprio link simbólico, mas sem ele, ele faz um , stat()portanto, desreferencia o link simbólico (e, se for stat()bem-sucedido, ls /proc/1/cwdlistaria o conteúdo do diretório de trabalho atual do pid 1).

    • 2

relate perguntas