As permissões do diretório pai são importantes ao acessar um subdiretório?

Se eu tiver uma pasta raiz com alguma permissão restritiva, digamos 600, e se as pastas / arquivos filhos tiverem 777 permissões, todos poderão ler / gravar / executar o arquivo filho, mesmo que a pasta raiz tenha 600?

A regra precisa é: você pode percorrer um diretório se e somente se tiver permissão de execução nele.

Portanto, por exemplo, para acessar dir/subdir/file, você precisa executar a permissão dire dir/subdir, além das permissões filedo tipo de acesso desejado. Entrando em casos extremos, não tenho certeza se é universal que você precise executar permissão no diretório atual para acessar um arquivo por um caminho relativo (o que você faz no Linux).

A maneira como você acessa um arquivo é importante. Por exemplo, se você tiver permissões de execução ativadas, /foo/barmas não ativadas /foo, mas o diretório atual estiver /foo/bar, poderá acessar os arquivos /foo/barpor um caminho relativo, mas não por um caminho absoluto. Você não pode mudar para /foo/barneste cenário; presumivelmente, um processo mais privilegiado foi feito cd /foo/barantes de ficar sem privilégios. Se um arquivo tiver vários links físicos, o caminho usado para acessá-lo determinará suas restrições de acesso.

Links simbólicos não mudam nada. O kernel usa os direitos de acesso do processo de chamada para atravessá-los. Por exemplo, se symé um link simbólico para o diretório dir, você precisa executar permissão dirpara acessar sym/foo. As permissões no próprio link simbólico podem ou não ser importantes, dependendo do sistema operacional e do sistema de arquivos (alguns as respeitam, outras as ignoram).

A remoção da permissão de execução do diretório raiz restringe efetivamente um usuário a uma parte da árvore de diretórios (na qual um processo mais privilegiado deve ser alterado). Isso requer listas de controle de acesso para qualquer uso. Por exemplo, se /e /homeestiver fora dos limites de joe( setfacl -m user:joe:0 / /home) e /home/joefor joeo diretório inicial, joenão será possível acessar o restante do sistema (incluindo a execução de scripts de shell com /bin/shbinários ou binários vinculados dinamicamente que precisem acessar /lib, então você ' d precisa ir mais fundo para uso prático, por exemplo setfacl -m user:joe:0 /*; setfacl -d user:joe /bin /lib).

A permissão de leitura em um diretório dá o direito de enumerar as entradas. Conceder permissão de execução sem conceder permissão de leitura é ocasionalmente útil: os nomes das entradas servem como senhas para acessá-las. Não consigo pensar em nenhuma utilidade em dar permissão de leitura ou gravação para um diretório sem permissão de execução.

Não. A permissão da pasta raiz limita a permissão de arquivos filho. Você pode experimentá-lo.

$ mkdir rootdir
$ touch ./rootdir/childfile
$ chmod 777 ./rootdir/childfile
$ chmod 600 rootdir
$ cat ./rootdir/childfile

Eu entendi isso:

$ cat: ./rootfolder/childfile: permission denied

Você pode tornar o diretório filho gravável, mesmo que o diretório pai não seja. Eu faço isso para grupos.

Por exemplo: o diretório pai pertence ao codificador do grupo

drwxr-sr-x

diretório filho

drwxrwsr-x

Você (qualquer membro do grupo de codificadores) ainda pode gravar no diretório filho, mas não no diretório pai.

Você pode criar o link físico para acessar o arquivo, mesmo que não tenha um privilégio de execução no diretório pai. Mas o problema aqui é que você deve criar o vínculo físico antes de perder o privilégio de execução no diretório pai

$ ln foo/bar/test_privs privs_test_checking