Por que as permissões de arquivos são retidas ao mover arquivos dentro do mesmo volume?

Question

Ocasionalmente, temos o problema de um arquivo ter permissões diferentes da pasta em que ele está.

Agora descobri que há um artigo da base de conhecimento explicando o motivo por trás disso:

By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

O usuário moveu o arquivo de uma pasta para outra e as permissões da pasta original foram mantidas.

Minha pergunta agora é: por que essa exceção existe? Qual é o raciocínio por trás disso?

    

Answer 1

Eu expliquei isso em um post de blog link , mas também é explicado abaixo.

Quando um arquivo é copiado, ele precisa criar um novo arquivo e atribuir um novo conjunto de permissões, para que ele obtenha as permissões da pasta pai, como você sabe.

Quando um arquivo é movido para outro volume, o que realmente acontece é que ele é copiado para o novo volume e o arquivo antigo é excluído. Assim, o mesmo processo é repetido como acima, pois é um novo arquivo novamente e precisa de permissões definidas.

Quando o arquivo é movido dentro do mesmo volume, nada realmente acontece (no nível do disco). Apenas altera a localização do caminho lógico do arquivo. Os dados reais e o arquivo físico no disco não foram tocados ou alterados. Já notou quando você move um arquivo de 5GB para outra pasta na mesma unidade, isso é feito quase que instantaneamente? É por isso que, na verdade, ele não foi movido, mas o ponteiro para onde o arquivo existe logicamente mudou. Como não foi modificado de forma alguma, as permissões também não mudam.

Esta é a razão para esse comportamento.

Edit: Algo que eu esqueci de mencionar ... O artigo da MS não é totalmente correto. Citação de MS:

By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

A citação acima se aplica somente aos objetos que receberam permissões SEC definidas EXPLICITAMENTE (desligue a herança). Como mencionado nos meus comentários, tudo se resume a manter as entradas da ACL tão eficientes quanto possível. Considere o seguinte exemplo:

Para manter a explicação simples, digamos que você tenha uma pasta definida para permitir que os usuários modifiquem apenas os direitos. Abaixo disso, existem milhares de arquivos e nenhum deles possui permissões explícitas. Não é muito eficiente criar ACLs para cada arquivo, pois eles são exatamente os mesmos perms, então ele define uma entrada ACL para a pasta. Este próximo bit é muito importante para entender; os próprios arquivos não têm ACL PERMS. Então, quando você move qualquer um desses arquivos para uma nova pasta no mesmo volume, o MS afirma que os perms se movem com ele (como na citação acima). Pergunte a si mesmo isso ... como? Não havia perms no arquivo em primeiro lugar para atravessar. Isso está incorreto e eu testei agora para confirmar. Digamos que a pasta de destino para a qual você está movendo o arquivo tenha perms para permitir que todos os grupos modifiquem apenas os direitos. Bem, como o arquivo não tem ACL diretamente, ele herda a ACL da pasta pai. Isso significa que os perms mudaram de modificador de usuários (pasta antiga) para todo mundo modificar (nova pasta).

Observe a diferença? Desta vez, mover um arquivo para outra pasta no mesmo volume realmente alterou os perms, algo que a MS diz que não faz. Acabei de encontrar um erro na documentação do MS desde 2000 lol ??

Agora, observe o mesmo cenário ao usar permissões explícitas. Se você definir permissões explícitas em um arquivo dentro dessa pasta (herança desativada) que, por exemplo, nega o acesso de leitura aos usuários, ele agora cria uma entrada NEW ACL especificamente para esse arquivo. Agora, quando você move o arquivo para um novo local, ele tem uma entrada de ACL diretamente relacionada a ele. Nesse caso, mover um arquivo para um novo local no mesmo volume RETENDE suas permissões (como as declarações do MS)!

    

Answer 2

Quando você está movendo arquivos dentro do mesmo volume você está tradicionalmente reorganizando seu sistema de arquivos . Alterar as permissões de arquivo no nível do diretório pode bloquear você nesse arquivo no momento em que a operação de movimentação é finalizada. Isso é indesejável se, por exemplo, você acidentalmente moveu um arquivo para um sistema, ou uma pasta com permissões especiais de propriedade ou protegida. Não haveria nenhuma maneira de corrigir o erro, a não ser apropriar-se do arquivo (se você tiver privilégios) ou fazer login com uma conta privilegiada. Considerando a operação normal do dia-a-dia de um computador, você poderia descobrir que não tinha controle sobre seu sistema de arquivos.

Esse comportamento é comum entre a maioria (se não todos) os sistemas operacionais que usam o ACL. Ele garante operações normais do sistema de arquivos dentro de um volume por usuários e aplicativos.

Por outro lado, ao mover arquivos entre volumes, você está tradicionalmente fornecendo um arquivo para controle por algo ou outra pessoa. Faz sentido, como você bem percebe, que o arquivo incorpore as permissões da pasta de destino, o que dará ao alvo as permissões necessárias para reorganizar seu próprio sistema de arquivos como achar melhor.

Naturalmente, isso nem sempre é desejável. Por esse motivo, as operações de movimentação e cópia podem ser definidas com regras de herança de permissão especial. Do mesmo artigo:

• Para preservar as permissões quando arquivos e pastas são copiados ou movidos, use o utilitário Xcopy.exe com a opção / O ou a opção / X. As permissões originais do objeto serão adicionadas a permissões herdáveis no novo local.

• Para adicionar permissões originais de um objeto a permissões herdáveis ao copiar ou mover um objeto, use o utilitário Xcopy.exe com as opções –O e –X.

Answer 3

OK Este é o verdadeiro resumo. Primeiro - estamos falando de um único PC ou de um servidor? Eu suponho que estamos falando de um servidor. Então ... como administrador da Wintel da empresa A você cria um sistema de arquivos em uma unidade de rede em seu novo servidor. Você o baseia nos departamentos, ou seja, cada departamento tem uma pasta e cada pasta tem sua própria ACL exclusiva devido a problemas de confidencialidade, como é provavelmente a norma - sim? Portanto, se você for mover um arquivo para a pasta de outro departamento, por que você não desejaria herdar o perms de sua nova pasta? O que quero dizer é ... por que um sistema de arquivos baseado em permissões se você não vai usá-lo? Eu posso dar-lhe um exemplo da vida real, onde é importante para os arquivos movidos / pastas para sempre herdar ACL da sua pasta-mãe, basta perguntar-me.

Mover arquivos dentro de um volume ou movê-los de vol X para vol Y ... qual é a diferença essencial? Você está movendo a localização de alguns arquivos - em diferentes volumes ou não faz pouca diferença em um ambiente corporativo, tanto quanto eu posso ver. A verdadeira razão pela qual um inclui a herança por padrão e o outro não foi mencionado por Mucker - isso é "eficiência". Arrastar e soltar arquivos dentro de um volume apenas altera a entrada Index - os arquivos não são movidos e suas informações de ACL são deixadas em paz. Faz uma operação simples. Quando os arquivos são movidos em volumes, no entanto, os arquivos e suas ACLs têm que serem redefinidos, por isso, fazer propriamente e incluir herança faz sentido, já que não implica sobrecarga.

Não consigo entender por que a Microsoft não resolve esse problema. Seria muito difícil incluir uma caixa de diálogo como parte do drop de arrastar do Explorer? Algo como "Você moveu arquivos para um local com diferentes direitos de acesso, deseja herdar as permissões da nova pasta pai? Y ou N?"

Atenciosamente, Stonegiant