Estou pesquisando o /procdiretório e, como usuário, não consigo listar um diretório, mesmo que mostre que o usuário é o proprietário.
Por que e como isso acontece?
Por exemplo, nele ls -l /proc/2323/map_filesdiz ls: reading directory '.': Permission denied. Mas o proprietário é claramente um usuário. O usuário pode fazer cd no diretório, mas não ls. Fazer isso como root é bom.
História de fundo adicionada:
Atualmente, o processo está usando o firejail, que é um binário setuid, para isolar letras maiúsculas e isolar o namespace do firefox. Sem o firejail, tudo funciona como esperado, ou seja, o usuário consegue ls map_files, mas com o firejail, o diretório map_files não pode ser lsdo usuário, embora cdesteja bem. Não é um problema de permissão, pois o diretório pode ser lido pelo usuário e os arquivos, que são links simbólicos para arquivos .so, também mostram u+r.
Responder1
Você pode remover a permissão de leitura de um arquivo de sua propriedade e não poderá mais lê-lo.
$ echo hello >foo
$ chmod u=w,go+r foo
$ ls -l foo
--w-rw-r-- 1 gilles gilles 6 Oct 20 15:13 foo
$ cat foo
cat: foo: Permission denied
Isto não é útil para segurança, pois o proprietário pode alterar as permissões do arquivo a qualquer momento. É apenas uma consequência de como as permissões funcionam.
No entanto, isso não explica o que você está vendo no /proc. /procé um sistema de arquivos um tanto especial. Com sistemas de arquivos “comuns”, quando um processo abre um arquivo (ou lista um diretório, ou lê o destino de um link simbólico), o kernel verifica as credenciais do processo (ou seja, qual usuário está executando e assim por diante), lê as permissões do arquivo e verifica se as credenciais dão acesso ao arquivo. Mas /procnão funciona assim. O kernel aplica verificações específicas, que são diferentes para diferentes arquivos no formato /proc. Separadamente, quando um processo lista um diretório, o kernel gera permissões que são uma aproximação das verificações realizadas ao abrir um arquivo.
Em particular, se um processo está ou esteve em execução com credenciais elevadas (normalmentesetuid ou setgid, algumas informações /procnão estão mais acessíveis ao usuário, apenas ao root. Isso não se reflete nas permissões. Por exemplo, considere um processo que esteja executando o setgid. Este processo terá todos os arquivos de /procpropriedade do usuário esperado e as permissões serão as mesmas dos processos sem privilégios. No entanto, como o processo pode ter tido acesso a informações confidenciais enquanto tinha privilégios extras de grupo, o kernel não permite mais que o usuário execute operações que possam exfiltrar essas informações. E assim, por exemplo, o usuário não consegue ver o que /proc/$pid/cwdaponta, caso o processo tenha mudado para um diretório que o usuário normalmente não consegue acessar. O usuário não pode despejar a memória do processo por meio do /proc/$pid/mem. O usuário não pode ver os mapas de memória do processo /proc/$pid/map*caso eles reflitam informações confidenciais (e também para manterASLReficaz). E assim por diante.
Responder2
Definir um arquivo pertencente ao usuário, mas que não pode ser lido pelo mesmo usuário, é realmente muito fácil:
chmod u-r file
Se você fizer isso - a única maneira de ler o arquivo seria elevar seus privilégios ou retornar o sinalizador de leitura ( u+r).
O mesmo vale para diretórios. Remova o sinalizador de leitura do usuário e o proprietário do diretório não conseguirá fazê- lslo. Remova o sinalizador executável do diretório ( u-x) e o proprietário perderá a capacidade de cdentrar nesse diretório.
Ao mesmo tempo - esses arquivos e diretórios podem ser acessados por outras pessoas ( o+re o+x). E é claro que eles estão sempre acessíveis porraizque ignora sinalizadores de permissão.
Diretórios e arquivos no /procdiretório representam processos, threads e objetos de memória compartilhada. Suas permissões são definidas pelo aplicativo quando ele cria o thread/memória compartilhada. Portanto, eles não respondem à chmodferramenta e tentar alterar a permissão é uma maneira segura de interromper o aplicativo em execução. Mas lse cdainda obedecer aos sinalizadores de permissão nos objetos em /proc. Então, se você realmente precisa ler alguma coisa lá - você tem que se elevarraiz.
Responder3
É causado pelos direitos do usuário.
exemplo:
[~] whoami
mm
[~] mkdir test
[~] echo "Hello World" > test/hello.txt
[~] ls -ld test
drwxr-xr-x 2 mm mm 4,0K 20. Okt 14:20 test
[~] chmod 111 test
[~] ls -ld test
d--x--x--x 2 mm mm 4,0K 20. Okt 14:20 test
[~] ls test
ls: cannot open directory 'test': Permission denied
[~, ERR:2] cat test/hello.txt
Hello World
[~] chmod 555 test
[~] ls -ld test
dr-xr-xr-x 2 mm mm 4,0K 20. Okt 14:20 test
[~] ls test
hello.txt
Os direitos das pastas são diferentes dos direitos dos arquivos. Isso xsignifica que você pode acessar a pasta, mas não pode examiná-la. Para examinar essa pasta, você rtambém precisará. E, claro, wsignifica que você pode escrever nessa pasta.