Como solucionar a falha de design de Mover / Copiar NTFS?

31

Como qualquer pessoa que tenha lidado com permissões de servidor de arquivos está ciente, o NTFS possui um recurso / falha de design interessante, conhecido como problema de Mover / Copiar.

Conforme explicado neste artigo do MS KB , as permissões para uma pasta ou arquivo não são herdadas automaticamente do pai, se a pasta for movida e a origem e o destino estiverem no mesmo volume NTFS. As permissões são herdadas se a pasta for copiada ou se a origem e o destino estiverem em volumes diferentes.

Aqui está um exemplo rápido:

Você tem duas pastas compartilhadas no mesmo volume NTFS chamado "Técnicos" e "Gerenciadores". O grupo Técnicos tem acesso RW à pasta Técnicos e o grupo Gerentes tem acesso RW à pasta "Gerenciadores". Se alguém tiver acesso a ambos e mover uma subpasta da pasta "Gerenciadores" para a pasta "Técnicos", a pasta movida ainda estará acessível apenas aos usuários do grupo "Gerenciadores". O grupo "Técnicos" não pode acessar a subpasta, mesmo que ela esteja na pasta "Técnicos" e deva estar herdando permissões da parte superior.

Como você pode imaginar, isso causa chamadas de suporte, tíquetes e ciclos desperdiçados na resolução desses problemas do usuário final, sem mencionar o ninho de permissões de ratos que você pode obter se os usuários frequentemente moverem pastas entre diferentes pastas / áreas protegidas no mesmo volume.

As perguntas são:

Qual é a melhor maneira de solucionar essa falha de design do NTFS e como você está lidando com isso em seu ambiente?

Eu sei que o artigo vinculado da KB fala sobre algumas chaves do Registro para alterar o comportamento padrão do Windows Explorer, mas elas são do lado do cliente e exigem que os usuários tenham a capacidade de alterar as permissões que eu pensaria na maioria dos ambientes, se você não deseja manter o controle sobre as permissões do servidor de arquivos (e sua sanidade como administrador de sistemas).

— David Archer
fonte

2

Eu sei que o exemplo de Gerentes / Técnicos é apenas para ilustrar a falha, mas, em alguns casos, é esse o comportamento que você deseja: se alguém mover acidentalmente a pasta de Gerentes para Técnicos, você provavelmente não deseja que os Técnicos possam acessar isto.

— Ala - Restabelecer Monica

2

Isso realmente não é uma falha, é assim que as permissões de arquivo funcionam. Está documentado desde o lançamento do NTFS. Não posso acreditar que algumas pessoas estejam recomendando não usar permissões de arquivo e apenas usar permissão de compartilhamento para controlar o acesso. Isso vai contra os princípios básicos de segurança de um servidor de arquivos da Microsoft. A razão pela qual mover uma pasta / arquivo no mesmo volume não herda é que a pasta / arquivo não se move realmente no disco, apenas o ponteiro que vemos muda.

— Michael Brown

12

Minha abordagem é não usar permissões de arquivo no nível de arquivo / diretório; use permissões no nível de compartilhamento de arquivos e defina a unidade de dados do sistema de arquivos do servidor inteiro como Everyone Full Control (que se torna discutível).

Ao longo dos anos (10+), eu descobri que as permissões NTFS são mais complexas e levam a mais erros. Se as permissões estiverem incorretas ou a herança for quebrada, você expõe os dados e é difícil encontrá-los e vê-los. Além disso, você está exposto ao problema de movimentação / cópia, como diz.

Locais onde você deve usar as ACLs no nível de diretório / arquivo; Não conheço outra solução senão verificar a saúde regularmente.

— James Risto
fonte

10

Bem, não é realmente uma falha. Esta regra para lidar com permissões ao mover arquivos existe desde pelo menos a versão beta 2 do NT3.1 (embora obviamente não seja uma herança, pois ela foi adicionada apenas no Windows 2000). É tão conhecido quanto qualquer recurso do Windows. Eu tenho muita simpatia por sua opinião, pois podem ser poucos de nós que não foram queimados por isso em um estágio. Mas é algo que o administrador do sistema aprende rapidamente.

JR

— John Rennie
fonte

6

Eu tive uma discussão com Raymond Chen em seu blog sobre isso. A Microsoft "vende" o NTFS como tendo permissão "herança" e depois recua quando essa brecha na armadura é levantada. O NTFS possui herança de permissão no momento da criação do arquivo, colocando ACEs explícitas nos arquivos quando eles são criados. Eu argumentaria que, desde que a documentação e a literatura de marketing falem sobre o sistema de herança como se fosse em tempo real a documentação ou o código é incorreto. Eles devem escolher um e consertá-lo.

— Evan Anderson

11

Bem, é uma troca. Se a herança fosse em tempo real, toda vez que você abrisse um arquivo na parte inferior de uma árvore profunda, o sistema operacional teria que executá-la para descobrir quais são as permissões efetivas. É claro que a desvantagem é que, se você alterar as permissões no topo de uma árvore profunda, terá uma espera muito longa! O Active Directory não usa o mesmo modelo?

— John Rennie

Os objetos do AD herdam corretamente as permissões do novo pai quando movidos entre contêineres e eu argumentaria que esse é o comportamento "correto" esperado ao mover arquivos / pastas no NTFS.

— 23415 David Archer

3

@renniej: O AD usa a verdadeira herança em tempo real. O sistema de arquivos Netware fez isso há séculos. O NTFS poderia ter feito isso também, se a Microsoft o tivesse implementado. É a "estrada não tomada". O que me incomoda é que a documentação da Microsoft re: NTFS e Explorer "reproduz" como se a herança fosse em tempo real (isto é, mentiras). Conte-nos como é, ou corrija o comportamento para acompanhar a documentação!

— Evan Anderson

@renniej Como Evan Anderson disse, a Netware fez isso em 1990 quando era rei. O problema é corrigível através da criação de outro índice do sistema de arquivos que rastreia a 'lista de visibilidade'. A Microsoft optou por não fazer isso, mas é possível conceber uma versão futura do Windows Server.

— sysadmin1138

6

Estamos usando o NTFS desde o NT 3.51 e, embora tenhamos visto esse "problema" (como quase todo mundo), não nos causou muitos problemas:

Sempre instruímos as pessoas a copiar arquivos, caso precisem movê-las de um diretório compartilhado para outro. "Mantenha pressionada a tecla CTRL ao arrastar e verifique se o pequeno + está aparecendo" é uma frase comum.
Nossas pastas compartilhadas têm uma estrutura bastante simples, e as pastas compartilhadas que criamos não passam entre grupos com muita frequência; portanto, é mais provável que as pessoas queiram copiar arquivos em primeiro lugar.
Vemos o problema principalmente em nosso espaço "comum" - pastas nas quais todos podem ler / gravar, mas esses diretórios são de curta duração, portanto o problema desaparece quando são eliminados.

— Ala - Restabelecer Monica
fonte

4

Soluções alternativas que posso pensar:

encontre uma maneira de tornar as pastas com permissões diferentes em volumes NTFS diferentes
Faça uma tarefa agendada (uma vez por hora ou uma vez por dia, dependendo da frequência das solicitações de suporte) que percorre as pastas e redefine todas as permissões para que sejam iguais às do nível superior. Isso é menos que o ideal, mais ainda se as pastas tiverem muitos arquivos, mas é algo que manteria o problema corrigido se não houvesse uma boa solução, como uma correção de registro no servidor. O comando que você deseja observar é chamado de 'cacls', que você pode adicionar a um arquivo em lotes.

Isenção de responsabilidade - venho de um plano de fundo unix (e implementei o último para corrigir falhas de permissões diferentes - parece nojento, mas faz o trabalho), portanto pode haver uma correção muito melhor.

— Marca
fonte

+1 - A primeira resposta que Marcos dá é a melhor escolha. É uma dor, mas é a melhor maneira de contornar esta decisão estúpido design em NTFS 5.

— Evan Anderson

Para expandir: Este é um local onde meus amigos que usam o SharePoint diriam "use SharePoint"! Da mesma forma, meus amigos de controle de versão e amigos de sistema de controle de documento apontariam para o Subversion, Documentum, etc, e diriam "use isso". Essa opção de design no NTFS é uma grande verruga e quase faz você se perguntar se a Microsoft realmente usa seu próprio software quando você precisa lutar com ele em sua própria rede. (Grita-me que a Microsoft não use o software da mesma maneira que usamos com nossos usuários. Deve ser bom ter uma empresa preenchida com "trabalhadores do conhecimento".)

— Evan Anderson

11

Concordo que, idealmente, poderíamos separar todas as pastas compartilhadas em seus próprios volumes, na prática isso é impraticável para um ambiente grande (milhares de pastas compartilhadas). Além disso, sem algum ponto de junção ou vodu simbólico, isso significa perder a capacidade de ter subpastas aninhadas com permissões diferentes.

— David Archer

11

@ David: Mover os dados entre compartilhamentos resultará em uma cópia e exclusão. Mover dados dentro de um compartilhamento resultará em uma mudança. Se você tornar cada pasta compartilhada a raiz de uma hierarquia de permissões, sem subpastas com permissão mais restritiva, você aliviará o problema. Ainda feio, no entanto. (Eu tenho um servidor W2K3 w / 2200+ pastas compartilhadas individuais sobre isso e eu não estou vendo problemas de desempenho ...)

— Evan Anderson

3

Ao mudar como administrador, uso xcopy / s / e / c / h / r / k / y - tudo além da propriedade do arquivo e da ACL, o que significa que a herança da ACL entra em ação automaticamente. Nunca realmente tive que lidar com uma situação em que um usuário coisas movidas embora.

— Maximus Minimus
fonte

2

Seus usuários estão vivos?

— Evan Anderson

4

Às vezes me pergunto ...

— Maximus Minimus

@ Mesmo: Talvez nenhum deles esteja em dois grupos!

— Samb

+1 para levar as pessoas à ferramenta que resolve esse problema ao manter arquivos (junto com muitos outros); no entanto, XCOPY foi depreciado: ROBOCOPY.EXE é seu sucessor muito capaz.

— jnaab

2

Desculpe pela nitpicking, mas não copia _copy_ os arquivos (em vez de _moving_ os arquivos?) - parece que o autor não tem problemas em copiar, ele só tem problemas em _moving_. Eu posso estar errado neste erro devido à minha falta de experiência; portanto, corrija-me se estiver errado (ou seja, você usa o comando 'del' depois de usar o 'xcopy', para que os arquivos sejam realmente 'copiados e excluídos'! = movido?)

— colemik

3

Eu uso a diretiva de grupo / diretivas de segurança / sistema de arquivos para acompanhar permissões complicadas. (NUNCA use a opção "substituir permissões" na política).

Programe um CACLS para redefinir toda a permissão durante a noite, seguido de um gpupdate / force para reaplicar a permissão da política. Funciona como um encanto.

— Alexandru Nica
fonte

Presumivelmente, isso é apenas para servidores Windows? Como a Diretiva de Grupo deve ser aplicada a objetos de domínio, isso não pode ser aplicado a compartilhamentos de armazenamento que não sejam do Windows, eu imagino?

— Rich M

2

Desde o Windows 7 (ou talvez o Windows Vista), as permissões para uma pasta ou arquivo herdam do pai, se a pasta for movida e a origem e o destino estiverem no mesmo volume NTFS - se um arquivo ou pasta estiver sendo copiado pelo Explorer. Em um sistema operacional anterior, você pode usar o Far manager - ele permite habilitar a herança de permissões do destino (junto com vários outros recursos). Embora Far possa parecer pouco amigável para um usuário geral.

— GCRaistlin
fonte

0

Uma solução muito simples é apenas compactar os arquivos e descompactá-los no diretório de destino.

— Prumo
fonte

Eu apenas tentei isso e, infelizmente, não funcionou. As permissões no arquivo zip são diferentes antes mesmo de eu fazer alguma coisa. As permissões herdadas permanecem, mas as explícitas não são criadas.

— Rich M