Concede acesso a um subdiretório sem fornecer acesso aos diretórios pai

Question

Eu tenho um cenário envolvendo um servidor de arquivos do Windows em que o "proprietário" quer distribuir permissões para um grupo de usuários da seguinte classificação:

• \server\dir1\dir2\dir3 : leia, escreva e execute
• \server\dir1\dir2 : sem permissões
• \server\dir1 : sem permissões
• \server : leia e execute

Para meu entendimento ( Atualização : Este parágrafo inteiro está errado!), não é possível fazer isso porque Read & Execute permission deve ser concedido a todos os pais diretórios em uma cadeia de diretórios para que o sistema operacional possa "ver" os diretórios filhos e chegar até eles. Sem essa permissão, você não pode nem obter o token de contexto de segurança ao tentar acessar o diretório aninhado, mesmo que tenha acesso total ao subdiretório.

Estamos procurando maneiras de contornar isso, sem mover os dados de \server\dir1\dir2\dir3 para \server\dir4 .

Uma solução que pensei, mas que não tenho certeza se funcionará, é criar algum tipo de link ou junção \server\dir4 , que é uma referência a \server\dir1\dir2\dir3 . Não tenho certeza de qual das opções disponíveis (se houver) funcionaria para essa finalidade se o usuário não tiver a permissão Read & Execute em \server\dir1\dir2 ou \server\dir1 , mas, até onde eu sei, as opções são:

• Link simbólico NTFS,
• Junção,
• Hard Link.

Então as perguntas:

• Algum desses métodos é adequado para atingir meu objetivo?
• Existem outros métodos de vincular ou fazer referência indireta a um diretório, que eu não listei acima, que possa ser adequado?
• Há alguma solução direta que não envolva a concessão de Read & Execute a \server\dir1 ou \server\dir2 , mas ainda permitindo acesso a \server\dir1\dir2\dir3 ?

Answer 1

Você está equivocado em sua suposição original, o que torna o restante da sua questão irrelevante.

A permissão mínima que um usuário precisaria em dir1 e dir2 é Traverse Directory . No entanto, isso provavelmente será problemático para seus usuários, então eu recomendaria Traverse Directory e List Folders . Eles poderão navegar pelos dois principais diretórios e acessar dir3 , onde eles têm mais permissões, mas nem mesmo verão quais arquivos existem nos dois diretórios superiores.

Permissões como Read & Execute e Modify são apenas coleções de permissões individuais. Eles são a primeira coisa que você vê, porque são os mais usados. Se você precisar ficar muito granular (como essa situação), clique no botão Advanced e entre nas opções listadas aqui.

    

Answer 2

Surpreendentemente, se o indivíduo tiver o caminho completo para uma subpasta na qual eles têm pelo menos R permissões, eles não precisarão de permissões em nenhuma das pastas pai, nem mesmo serão executadas. Eles podem simplesmente acessá-lo usando o UNC. (Eles devem, é claro, ter permissões de leitura no compartilhamento; não apenas em pastas acima do nível que desejam acessar).

Eu não acreditei nisso quando me disseram, mas o teste prova isso.

Isso é contra o que eu achava que sabia sobre permissões no mundo do Windows, e eu suspeito que será uma surpresa para muitos.

\ server \ folder1 \ folder2 \ folder3

Se não houver permissões para o Bilbo na pasta1 e na pasta2, mas o Bilbo tiver modificação (por exemplo) na pasta3, \ server \ folder1 \ folder2 \ folder3 o levará para lá, sem problemas.

    

Answer 3

Uma solução semelhante ao MDMarra é definir permissões de NTFS da seguinte forma:

1. dir1 : Conceder Listar conteúdo da pasta (Atravessar pasta / executar arquivo, Listar pasta / ler dados, Ler atributos, Ler atributos estendidos, Ler permissões)
2. MAS selecione Somente esta pasta para Aplicar ao menu suspenso
3. dir2 : Conceder Listar conteúdo da pasta e Aplicar a Esta pasta apenas
4. dir3 : Conceda permissões de Leitura / Escrita desejadas e Aplique a Esta pasta, subpastas e arquivos ou Apenas subpastas e arquivos

O resultado final é que o usuário / grupo pode ler cada pasta pai individual e detalhar a pasta filha sem outras pastas ou arquivos.

    

Answer 4

Portanto, testei isso no ambiente a seguir, pois queria obter uma resposta final e testada, com o mínimo necessário de permissões para simplesmente percorrer pastas por meio da navegação (por exemplo, pelo Windows File Explorer). Aqui estão os resultados para aqueles que querem bloquear as coisas.

Eu não testei isso em produção ainda para ver se há efeitos colaterais estranhos ao reduzir o modelo de direitos de passagem bem testado "padrão" de

• Atravessar pasta
• Listar pasta
• Atributos de leitura
• Leia o ramal Atributos
• Permissões de leitura

... que é basicamente apenas as permissões normais "Ler e executar" limitadas a "Esta pasta". Dito isso, os testes em pequena escala têm sido completamente bons até agora para os usuários simplesmente moverem, copiarem e removerem arquivos no servidor e os usuários trabalharem completamente fora das cópias de documentos do servidor, etc.

Ambiente:

• Servidor : Windows 2008 R2 - pouca ou nenhuma diretiva de grupo, nada mudou em relação aos direitos do usuário, configurado como controlador de domínio, DNS integrado ao AD, configuração muito básica / básica .
• Cliente : Windows 7 SP1 - Instalação limpa em uma VM, reiniciada entre as alterações para garantir que a conexão com o servidor seja totalmente recriada a cada vez.
• Ambas as instalações foram corrigidas pelo menos até o final de 2017, o que provavelmente é atual para qualquer coisa relacionada a permissões que estejam muito bem incorporadas neste momento na linha do tempo do Windows.
• Isso estava acessando uma pasta compartilhada montada como uma unidade de rede persistente (\ server \ share - > S :) na VM. As permissões de compartilhamento eram do grupo Ler + alterar para usuários autenticados, que abrange o usuário de teste e todos os outros que provavelmente precisarão acessar em algum momento.
• Após cada alteração, eu reinicio a VM, abro o Gerenciador de arquivos e simplesmente navego no compartilhamento normalmente, indo por um caminho que eu sabia que o usuário de teste tinha esses direitos de passagem nos que não tinha.

Resultados:

• Obrigatório na pasta raiz : ListFolder-ReadData + ReadAttributes (2x permissões)
• Obrigatório nas subpastas : ListFolder-ReadData (1x permissão)

• Opcional : TraverseFolder - ExecuteFile

  - > Essa permissão opcional só é importante se o direito Ignorar a Verificação Completa do Usuário tiver sido explicitamente proibido, já que está ativado por padrão em 99% das circunstâncias. Colocado de forma diferente, o direito de usuário "Ignorar a Verificação Completa" (exposto na Diretiva de Grupo, não em permissões de arquivo / pasta NTFS) ativado impede esse privilégio completamente e efetivamente torna esse privilégio habilitado em todos os lugares por padrão. Nota: Eu não testei para ver se uma negação explícita desse direito, por sua vez, impediria que o direito de ignorar a verificação completa tivesse efeito naquela instância específica, mas poderia).

Informações suplementares: O direito de usuário "Ignorar Verificação Completa" permite que alguém passe passivamente para uma subpasta, no entanto com muitos níveis de profundidade, a que tenha acesso diretamente (ou seja, as permissões são definidas nesse arquivo / pasta, mas não necessariamente em qualquer lugar mais adiante o caminho do arquivo).