As pastas de nível superior mostram as permissões herdadas do objeto pai - quem é o pai / mãe?

Question

Olhando para um servidor Windows 2012 R2 que tem D: \ Users, D: \ Admin, D: \ Repository e alguns mais como os que são compartilhados.

Ao analisar a segurança, eles mostram permissões herdadas do objeto pai.

Parece-me que seria D: \ e isso mostraria herança de D: \

O que é o objeto pai e depois para essas pastas? Eles não são sub-pastas de nada.

Se eu criar uma nova pasta, mostrarei como seria de esperar antes de quaisquer ajustes herdados de D: \ - no Parent Object.

O proprietário dessas pastas existentes é Administradores (DOMAIN-NAME \ Administrators).

Desculpe se esta é uma pergunta total, mas ainda não vi isso antes.

    

Answer 1

Uma maneira que isso pode ser causado (embora eu não possa dizer que não é exatamente a causa do que você está vendo) é por movendo diretórios no volume depois que eles tiveram permissões aplicadas a partir de um objeto pai . As permissões de objeto são adicionadas no momento da criação e, embora pareça que a Microsoft "alterou as regras" um pouco ao longo do tempo (veja meus comentários abaixo), suspeito que ainda existam casos críticos no código onde isso é verdade. .

Parece que o Windows Server 2012 tenta muito mais do que as versões anteriores do Windows para "corrigir" esse comportamento. Aqui estão instruções para reproduzir o comportamento no Windows Server 2008, no entanto:

• Crie uma pasta "D: \ Test"
• Edite a permissão NTFS e adicione "Convidados / Controle total" à pasta "D: \ Test"
• Crie uma pasta filha "D: \ Test \ Test-Child"
• De um prompt de comando elevado, execute move D:\Test\Test-Child D:\ .

Quando você examinar as permissões da pasta "D: \ Test-Child", verá "Guests / Full Control" sendo herdado do "Parent Object".

Eu não posso reproduzir isso no Windows Server 2012, o que me diz que a Microsoft adicionou algum código para cobrir esse caso de borda específico.

Raymond Chen postou sobre esse comportamento em seu blog 2006. Eu comentou sobre isso, dizendo que era uma falha de projeto . Acho interessante que, anos depois, outra pessoa da Microsoft concordou e mudou o comportamento.