Acessando arquivos em um diretório sem permissão x?


19

Estou com problemas para entender o que significa a permissão de execução para diretórios. Entendi corretamente que qualquer coisa em um diretório para a qual um usuário não possui direitos x é inacessível, mesmo que as coisas contidas no diretório concedam direitos específicos ao usuário?

Ou o usuário ainda terá acesso direto às coisas no diretório, mas simplesmente não pode listar o que está no diretório?

(O que realmente estou tentando entender é como um diretório está protegido contra o acesso de outros usuários, se eles não tiverem permissão x.)

Respostas:


20

O bit x do diretório também é chamado de bit de pesquisa. Na verdade, ele permite acessar os inodes dos arquivos listados dentro da pasta. Portanto, se você deseja acessar /home/user/foo/bar.txt, deve ter acesso de pesquisa em todos os ancestrais de bar.txt

Citando a partir da página

Como os diretórios não são usados ​​da mesma maneira que os arquivos comuns, as permissões funcionam de maneira um pouco (mas apenas um pouco) diferente. Uma tentativa de listar os arquivos em um diretório requer permissão de leitura para o diretório, mas não nos arquivos. Uma tentativa de adicionar um arquivo a um diretório, excluir um arquivo de um diretório ou renomear um arquivo exige uma permissão de gravação para o diretório, mas (talvez surpreendentemente) não para os arquivos contidos nele. A permissão de execução não se aplica aos diretórios (um diretório também não pode ser um programa). Mas esse bit de permissão é reutilizado para diretórios para outros fins.

A permissão de execução é necessária em um diretório para poder entrar nele (ou seja, tornar algum diretório seu diretório de trabalho atual).

A execução é necessária em um diretório para acessar as informações do inode dos arquivos contidos. Você precisa disso para procurar um diretório para ler os inodes dos arquivos. Por esse motivo, a permissão de execução em um diretório geralmente é chamada de permissão de pesquisa.

A permissão de pesquisa é necessária em muitas situações comuns. Considere o comando cat / home / user / foo. Este comando claramente requer permissão de leitura para o arquivo foo. Mas, a menos que você tenha permissão de pesquisa nos diretórios /, / home e / home / user, o gato não pode localizar o inode do foo e, portanto, não pode lê-lo! Você precisa de permissão de pesquisa em cada diretório ancestral para acessar o inode de qualquer arquivo (ou diretório) e não pode ler um arquivo a menos que possa acessá-lo.

Leia mais na seção do diretório de permissão de arquivo.

Atualização: Leo levantou uma pergunta muito boa. Se conhecemos o inode, podemos acessar um arquivo a partir de um diretório com o bit x desabilitado? Eu acredito que não devemos ser capazes de fazê-lo. Eu não o testei pelo programa c, mas usei alguns comandos úteis do bash para confirmá-lo.

user@user-desktop:~/test$ ls -lart
total 12
drwxr-xr-x 49 user user 4096 2011-11-30 22:37 ..
drwxr-xr-x  3 user user 4096 2011-11-30 22:37 .
drwxr-xr-x  2 user user 4096 2011-11-30 22:38 level1
user@user-desktop:~/test$ ls -lart level1/
total 12
drwxr-xr-x 3 user user 4096 2011-11-30 22:37 ..
drwxr-xr-x 2 user user 4096 2011-11-30 22:38 .
-rw-r--r-- 1 user user    8 2011-11-30 22:38 file1
user@user-desktop:~/test$ stat level1
  File: `level1'
  Size: 4096        Blocks: 8          IO Block: 4096   directory
Device: 808h/2056d  Inode: 95494       Links: 2
Access: (0755/drwxr-xr-x)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2011-11-30 22:46:16.576702105 +0530
Modify: 2011-11-30 22:38:12.386701913 +0530
Change: 2011-11-30 22:46:08.876702102 +0530
user@user-desktop:~/test$ stat level1/file1 
  File: `level1/file1'
  Size: 8           Blocks: 8          IO Block: 4096   regular file
Device: 808h/2056d  Inode: 60775       Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/    user)   Gid: ( 1000/    user)
Access: 2011-11-30 22:38:19.846701917 +0530
Modify: 2011-11-30 22:38:16.366701915 +0530
Change: 2011-11-30 22:38:16.366701915 +0530
user@user-desktop:~/test$ chmod -x level1
user@user-desktop:~/test$ stat level1/file1 
stat: cannot stat `level1/file1': Permission denied
user@user-desktop:~/test$ ls -lart level1/
ls: cannot access level1/..: Permission denied
ls: cannot access level1/.: Permission denied
ls: cannot access level1/file1: Permission denied
total 0
-????????? ? ? ? ?                ? file1
d????????? ? ? ? ?                ? ..
d????????? ? ? ? ?                ? .
user@user-desktop:~/test$ cat level1/file1
cat: level1/file1: Permission denied
user@user-desktop:~/test$ find . -inum 95494
./level1
user@user-desktop:~/test$ find . -inum 60775
user@user-desktop:~/test$ find ./level -inum 60775
find: `./level': No such file or directory
user@user-desktop:~/test$ find ./level1 -inum 60775

2
Portanto, se eu tiver o número de inode de um arquivo / diretório dentro de um diretório sem direitos de pesquisa, seria capaz de acessá-lo enquanto suas permissões permitirem? (Obter o número do inode sem poder fazer stat é muito difícil, embora eu suponha.) #
30311 Leo

@ Leo Eu acredito, não devemos ser capazes de fazê-lo. Eu atualizei a resposta. Se você tem um pequeno esboço, verifique-o e informe-nos.
Amey Jah

1
@AmeyJah, na verdade, eu aposto que você pode. Considere o que acontece quando você vincula um arquivo a outro diretório ao qual você tem permissão. O mesmo inode, mas você pode lê-lo. Em outras palavras, a permissão de leitura não depende do sistema procurar todas as pastas às quais o inode possa pertencer e ver se eles possuem o bit x. Ótima resposta embora. Muito obrigado.
User1477

@AmeyJah ls , stat etc. use stat (2) etc. Caso você não saiba até agora. Eu poderia escrever um programa em C, mas seu teste faz tudo o que o programa mostraria, mas com certeza ele poderia fazer mais, o ponto é o mesmo: ele usa os syscalls (seção 2). As chamadas da biblioteca (seção 3) são de nível superior ao syscalls, mas isso não muda nada (por exemplo, remove (3) usa rmdir (2) para diretórios e desvincula (2) para arquivos).
Pryftan

5

Como você está solicitando diretórios:

read significa: leia o conteúdo, ou seja, liste-o com ls.

escrever significa: escreva para o diretor. isto é, criando arquivos ou subdiretórios.

execute significa: entre nesse diretório.

permissões de leitura e execução podem ser um pouco complicadas para diretórios.

Por exemplo, se você possui permissões de leitura, mas não executa, pode listar o conteúdo do diretório, mas não pode cair nele. Além disso, você não pode listar arquivos ou diretórios específicos, mesmo sabendo seus nomes.

Se você tiver permissão de execução, mas não for lida, poderá soltá-la, mas não poderá listar os arquivos diretamente. Mas, se você souber os nomes dos arquivos ou diretórios, poderá listá-los.


2
Se você tiver permissão de leitura, mas não executar, poderá listar (ls) o conteúdo do diretório, mas não poderá acessar (cat) os arquivos nele. Se você possui permissão de execução, mas não lê, e conhece os nomes dos arquivos, pode acessá-los (cat).
dash17291

2

A permissão de execução nos diretórios significa:

A capacidade de entrar nesse diretório e acessar os arquivos nesse diretório.

Se você não tem o xdireito em seu diretório, não poderá:

  • Entre no diretório (ou seja cd:)
  • Não é possível acessar nenhum arquivo neste diretório (mesmo que você saiba o nome).

Exemplo:

$ ls -ld testdir
drw------- 2 xxxxxx xxxxxx 14 2011-11-29 19:38 testdir

$ cd testdir
bash: cd: testdir: Permission denied

$ cat testdir/a
cat: testdir/a: Permission denied

$ chmod 700 testdir
$ cat testdir/a
Some text.

Leia Linux File Permission Confusion pt 2 para obter uma boa introdução sobre o tópico.

A única coisa que a xpermissão parece não impedir é acessar os nomes dos arquivos nesse diretório.

Exemplo:

$ ls -ld testdir
drw------- 2 xxxxxx xxxxxx 14 2011-11-29 19:38 testdir

$ ls testdir
ls: cannot access testdir/a: Permission denied
ls: cannot access testdir/b: Permission denied
a  b
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.