Permissões que restauram do Time Machine - cópia do Finder versus cópia "cp"

7

Nota: esta questão estava começando a se espalhar, então eu a reescrevi.

Eu tenho uma pasta que estou tentando restaurar de um backup do Time Machine. Usar cp -R funciona bem, mas algumas pastas não podem ser restauradas com a interface do usuário ou o localizador do Time Machine.

Outros usuários relataram erros semelhantes e a solução cp -R foi sugerida (por exemplo, Restaurando do Time Machine - Erro de Permissões . Mas eu queria entender:

  1. Por que cp -R funciona quando o Finder e a interface do usuário do Time Machine não.
  2. Se eu poderia evitar os erros alterando as permissões de arquivo antes do backup.

Parece haver algumas permissões com as quais o Finder trabalha e outras que não. Eu reduzi os erros para pastas com o usuário ben (sou eu) e o grupo wheel .

Aqui está uma reprodução simplificada. Eu tenho quatro pastas com as combinações de proprietário / grupo que vi até agora:

ben ~/Desktop/test $ ls -lea
total 16
drwxr-xr-x   7 ben   staff   238 27 Nov 14:31 .
drwx------+ 17 ben   staff   578 27 Nov 14:29 ..
 0: group:everyone deny delete
-rw-r--r--@  1 ben   staff  6148 27 Nov 14:31 .DS_Store
drwxr-xr-x   3 ben   staff   102 27 Nov 14:30 ben-staff
drwxr-xr-x   3 ben   wheel   102 27 Nov 14:30 ben-wheel
drwxr-xr-x   3 root  admin   102 27 Nov 14:31 root-admin
drwxr-xr-x   3 root  wheel   102 27 Nov 14:31 root-wheel

Cada um contém um único arquivo chamado file com o mesmo proprietário / grupo:

ben ~/Desktop/test $ cd ben-staff
ben ~/Desktop/test/ben-staff $ ls -lea
total 0
drwxr-xr-x  3 ben  staff  102 27 Nov 14:30 .
drwxr-xr-x  7 ben  staff  238 27 Nov 14:31 ..
-rw-r--r--  1 ben  staff    0 27 Nov 14:30 file

No backup, eles se parecem com isso:

ben /Volumes/Deimos/Backups.backupdb/Ben’s MacBook Air/Latest/Macintosh HD/Users/ben/Desktop/test $ ls -leA
total 16
-rw-r--r--@ 1 ben   staff  6148 27 Nov 14:34 .DS_Store
 0: group:everyone deny write,delete,append,writeattr,writeextattr,chown
drwxr-xr-x@ 3 ben   staff   102 27 Nov 14:51 ben-staff
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 ben   wheel   102 27 Nov 14:51 ben-wheel
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 root  admin   102 27 Nov 14:52 root-admin
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown
drwxr-xr-x@ 3 root  wheel   102 27 Nov 14:52 root-wheel
 0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

Destes, ben-staff pode ser restaurado com o Finder sem erros. root-wheel e root-admin pedem minha senha e restauram sem erros. Mas ben-wheel não solicita minha senha e apresenta o erro:

The operation can’t be completed because you don’t have permission to access “file”.

Curiosamente, eu posso restaurar o file desta pasta arrastando-o diretamente para minha unidade local (em vez de arrastar sua pasta pai), mas quando faço isso, suas permissões são alteradas para ben / staff .

Aqui estão as permissões após a restauração das três pastas que funcionaram corretamente e o arquivo de ben-wheel que foi alterado para ben / staff .

ben ~/Desktop/test-restore $ ls -leA
total 16
-rw-r--r--@ 1 ben   staff  6148 27 Nov 14:46 .DS_Store
drwxr-xr-x  3 ben   staff   102 27 Nov 14:30 ben-staff
-rw-r--r--  1 ben   staff     0 27 Nov 14:30 file
drwxr-xr-x  3 root  admin   102 27 Nov 14:31 root-admin
drwxr-xr-x  3 root  wheel   102 27 Nov 14:31 root-wheel

Alguém pode explicar esse comportamento? Por que o Finder e a interface do usuário do Time Machine quebram com as permissões ben / wheel ? E por que cp -R funciona (mesmo sem sudo )?

    
por Ben Challenor 27.11.2011 / 14:35

3 respostas

6

O problema aqui é que o Finder implementa o tratamento especial de arquivos restaurados do Time Machine para preservar todas as suas permissões, que falharam em arquivos pertencentes à conta do usuário atual, mas não em um grupo do qual ele é membro.

Geralmente, ao copiar arquivos usando cp , seus atributos não são retidos. Isso pode ser alterado usando a opção -p .

-p Cause cp to preserve the following attributes of each source file in the copy: modification time, access time, file flags, file mode, user ID, and group ID, as allowed by permissions. Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks, will also be preserved.

Em ambos os casos, você copia todos ou nenhum ou esses metadados. cp é inteligente o suficiente para restaurá-los somente depois que todos os arquivos contidos tiverem sido processados ([ source , veja perto de If -p is in effect, set all the attributes ).

Se você não tiver permissões de root, a propriedade não será retida. A razão para isso é que somente o root pode criar arquivos pertencentes a usuários e não a ele e a grupos dos quais ele não é membro.

Para tornar os backups do Time Machine visíveis, mas imutáveis no Finder, eles são protegidos por listas de controle de acesso que negam a todos os usuários todas as permissões de modificação.

0: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown

Como outros atributos (outras ACLs, atributos estendidos, datas de arquivos e permissões) devem ser mantidos durante a restauração do backup, o tratamento especial dessas pastas é necessário no Finder. Ele deve remover uma entrada específica da ACL, mas reter todo o resto.

Além disso, a Apple aparentemente quer que o Finder retenha todas as informações de propriedade ao copiar arquivos e diretórios do backup. Isso inclui os membros do grupo .

Se a sua conta não for a proprietária dos diretórios em questão, o Finder solicita uma senha de administrador e transfere a cópia para o programa auxiliar de privilégios elevados Locum . Isso não acontece quando você é o proprietário de um arquivo no conjunto de backup.

Agora, um dos seguintes casos acontece:

  • Você não é <<> o proprietário do arquivo: o Finder solicita sua senha, o Locum restaura todas as permissões como no backup.
  • Você é o proprietário e um membro do grupo do arquivo: o Finder copia o arquivo e restaura o grupo.
  • Você é o proprietário mas não membro do grupo do arquivo: o Finder copia o arquivo e não restaura o grupo.

É como se estivesse tentando chown username:groupname do arquivo e imprime um erro se falhar - o que acontece se você não for root ( sudo ) nem username e membro groupname .

Ela se comporta de maneira ligeiramente diferente se você não estiver copiando pastas, mas arquivos: Embora a propriedade do arquivo seja mantida, a associação ao grupo será descartada se você não for um membro do grupo. Isto é o que você viu quando copiou apenas um único arquivo.

As soluções óbvias para este problema:

  • Impeça que propriedades de arquivos causem falha na restauração (ou seja, que seja de sua propriedade e de um grupo que você não é ) - na maioria das vezes, isso não é útil de qualquer maneira
  • Torne-se membro desse grupo específico, pelo menos temporariamente. Infelizmente, não consegui fazer isso usando dscl da linha de comando de uma maneira que teve um efeito sem sair ou reiniciar. Outro efeito colateral é que, com wheel , você pode ter problemas com permissões, dependendo da configuração do seu sistema.
por 27.11.2011 / 21:53
9

Além das permissões normais de arquivo UNIX (usuário / grupo / todos, cada um com suas próprias permissões de leitura / gravação / execução), o Mac OS X também usa Listas de Controle de Acesso (ACLs) que permitem configurações muito mais granulares de permissões de arquivos / pastas. p>

O Time Machine adiciona (pré-anexa) a seguinte ACL a todos os arquivos:

group: todos negam add_file, delete, add_subdirectory, delete_child, writeattr, writeextattr, chown

(A ACL acima é específica da pasta, mas é mapeada para arquivos regulares como: add_file = write, add_subdirectory = append, delete_child = < none >)

Isso significa que todos os arquivos / pastas dentro de um backup do Time Machine estão bloqueados para todos (até mesmo para o usuário root).

Se você restaurar seus arquivos manualmente a partir de um Backup do Time Machine (ou seja, se você não usar o Assistente de Migração), todos os seus arquivos manterão essas aborrecidas ACLs do Time Machine anexadas a eles.

É muito fácil remover as ACLs do Time Machine. Você tem três opções:

1) Balance o machado e remova totalmente as ACLs de seus arquivos / pastas (nada de errado com isso, mas não com uma estratégia muito cautelosa)

2) Remova a primeira entrada das ACLs de seus arquivos / pastas (mais cautelosa, mas não uma solução perfeita)

3) Remova restrições específicas das ACLs de seus arquivos / pastas (provavelmente sua melhor aposta se você quiser preservar ACLs não impostas pelo Time Machine)

Para todas as três opções, você precisa do Terminal, que você encontrará em / Aplicativos / Utilitários

Opção 1: Veja como você gira o machado:

Se você sabe que tem apenas seus arquivos pessoais em uma pasta chamada "Meus arquivos recuperados" em sua área de trabalho e sabe que esses arquivos não precisam de nenhuma ACL sofisticada, você pode digitar o seguinte na janela do Terminal:

chmod -R -N ~ / Desktop / My \ Recovered \ Files

(se você não souber o modo Terminal de especificar um arquivo / pasta, simplesmente arraste e solte o arquivo / pasta que deseja na janela do Terminal e o Terminal irá digitar o nome correto do arquivo / pasta para você)

Opção 2: veja como você remove a primeira entrada da ACL

O mesmo exemplo acima. Você tem uma pasta chamada "My Recovered Files" na sua área de trabalho. Mas nesse caso você tem alguns arquivos com ACLs personalizados que deseja preservar. Digite o seguinte na janela do Terminal:

chmod -R -a # 0 ~ / Desktop / Meu \ Recuperado \ Arquivos

O que torna a solução acima "perigosa" é que ela não é idempotente. Uma operação idempotente é uma operação que pode ser aplicada repetidamente sem alterar o resultado depois de ter sido aplicada uma vez. É como multiplicar um número por 1. Você pode continuar fazendo isso, mas o resultado é sempre o mesmo.

Por que isso importa? Bem, digamos que você tenha um arquivo que já tenha uma ACL antes que o Time Machine tenha anexado sua própria entrada da ACL. Se você executar o comando acima duas vezes, terá removido a ACL do Time Machine e a ACL que provavelmente não queria perder.

Além disso, a solução acima também não é ideal para arquivos do Time Machine que são misturados com outros arquivos. Se qualquer um desses outros arquivos (que não são do Time Machine) tiverem ACLs, o comando acima removerá essas ACLs.

Opção 3: veja como você remove restrições específicas de uma ACL

Além de poder especificar qual entrada numérica de uma ACL você deseja remover, você também pode especificar as restrições específicas que deseja remover. Então você poderia fazer isso:

chmod -R -a "grupo: todos negam add_file, delete, add_subdirectory, delete_child, writeattr, writeextattr, chown" ~

("~" significa "meu diretório pessoal", ou seja, se seu nome de usuário for bob, então "~"="/ Users / bob")

O comando acima é idempotente, o que significa que você pode executá-lo repetidas vezes sem efeito negativo. Na verdade, qualquer um pode executá-lo a qualquer momento. Se não houver arquivos / pastas que foram bloqueados pelo Time Machine em seu diretório home, nada acontecerá.

OK. Espero que isso tenha sido útil para algumas pessoas. Eu tive o mesmo problema com as permissões do Time Machine ontem, então imaginei que compartilharia o que descobri.

    
por 16.01.2012 / 11:35
6

Na verdade, você deve usar o tmutil para restaurar arquivos de seus backups do Time Machine. Desta forma, você não terá que remover os atributos estendidos, etc.

Na página de manual do Mac OS X :

tmutil restore [-v] src ... dst

Restore the item src, which is inside a snapshot, to the location dst. The dst argument mimics the destination path semantics of the cp tool. You may provide multiple source paths to restore. The last path argument must be a destination.

When using the restore verb, tmutil behaves largely like Finder. Custom Time Machine metadata (extended security and other) will be removed from the restored data, and other metadata will be preserved.

Root privileges are not strictly required to perform restores, but tmutil does no permissions preflighting to determine your ability to restore src or its descendants. Therefore, depending on what you're restoring, you may need root privileges to perform the restore, and you should know this ahead of time. This is the same behavior you would encounter with other copy tools such as cp or ditto. When restoring with tmutil as root, ownership of the restored items will match the state of the items in the backup.

Então basicamente você pode usá-lo como o comando cp sem se preocupar com o resto interno.

Na maioria dos casos, você deseja restaurar com o sudo, quando não sabe, se é o proprietário dos arquivos ou se possui permissões de gravação para o diretório de destino.

    
por 11.12.2013 / 19:11