Aws-cli: A sincronização s3 não preserva as permissões entre os intervalos

Todos os arquivos têm as mesmas permissões? Porque, por enquanto, você pode executar o comando sync com --acl para definir as permissões. No entanto, a execução do comando sync sem nenhum outro argumento opcional não procura permissões e garante que, quando o objeto for transferido, ele tenha as mesmas permissões do objeto original. Teríamos que adicionar um argumento / recurso adicional para lidar com isso.

Não - se todos os arquivos tivessem as mesmas permissões, eu poderia usar o sinalizador --acl.

Esse recurso é realmente essencial para um mecanismo de sincronização, principalmente quando você tem milhares de arquivos com permissões diferentes e deseja uma sincronização verdadeira entre depósitos, não apenas uma cópia dos arquivos.

Você conhece outra maneira de obter permissões por arquivo, para que eu possa fazer o script com facilidade?

Obrigado por ajudar.

Sim, se você executar um aws s3api get-object-acl em cada um dos objetos. Você poderia obter acl's. Aqui estão os documentos do comando.
http://docs.aws.amazon.com/cli/latest/reference/s3api/get-object-acl.html

OK - obrigado, isso funcionará, mas esse recurso ainda seria muito apreciado na sincronização, se não por padrão, a sinalização --preserve-s3-acl seria suficiente.

Sem problemas. Irá considerar o recurso. Eu acredito que o motivo pelo qual não foi implementado é porque a operação em si pode ser cara. Para determinar os objetos em um depósito s3, uma chamada para ListObjects é feita, no entanto, isso não retorna os acls para cada objeto. Por sua vez, teríamos que voltar e executar GetObjectAcl em cada objeto listado, o que pode demorar um pouco se houver milhares de itens no balde.

Como demorei algum tempo para descobrir que as permissões não foram sincronizadas, talvez atualizar as documentações de s3 para s3 sync para mencionar que apenas os dados sem as permissões são sincronizados economizaria tempo de outra pessoa no futuro.

obrigado novamente

alguma atualização sobre isso?

Eu adicionei uma solicitação pull (# 1535) para resolver isso (também outras transferências S3 para S3, como copy ) algumas semanas atrás. Alguma chance de tê-lo considerado para inclusão?

Olá, sei que é um tópico antigo, mas resolvemos isso por meio de uma sincronização por tipo de permissão. Resumindo: você pode filtrar sua sincronização por nome de chave com --exclude e --include, também pode especificar a ACL de cada sincronização ... Então, se você tiver um padrão de chaves com você precisa definir permissões diferentes, execute comando de sincronização muitas vezes que você precisa com diferentes opções de ACLs. Está longe do ideal, mas funciona!

Alguma opinião da equipe AWS?

Estou enviando meus repositórios git para o S3 apenas para backups. E então, quando eu os sincronizo novamente, todos os tipos de permissões foram alterados.

Todos os meus arquivos bin executáveis ​​não são mais executáveis ​​e git status reclama sobre isso.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1, Sim, tive meus baldes nomeados com um ponto, tive que mudar para ser compatível com https por meio da nuvem. Sincronizado com novos intervalos nomeados corretamente. Não é possível acessar arquivos. Leia sobre as permissões. Existem permissões de nível de objeto. Nenhum comando para alterar todas as permissões de nível de objeto em um intervalo. Querendo saber como proceder. As permissões por meio da GUI do aws parecem iguais em ambos os depósitos, mas ao pesquisar a Lista de controle de acesso por meio do cli, vejo que o depósito original tinha um outorgado extra que não foi copiado.
{
"Beneficiário": {
"Tipo": "Grupo",
"URI": " http://acs.amazonaws.com/groups/global/AllUsers "
},
"Permissão": "LEIA"
}

Bom Dia!

Estamos encerrando esse problema aqui no GitHub, como parte de nossa migração para o UserVoice para solicitações de recursos envolvendo o AWS CLI.

Isso nos permitirá fornecer os recursos mais importantes para você, tornando mais fácil pesquisar e mostrar suporte para os recursos que você mais gosta, sem diluir a conversa com relatórios de bug.

Como uma cartilha rápida do UserVoice (se ainda não for familiar): depois que uma ideia é postada, as pessoas podem votar nas ideias e a equipe do produto responderá diretamente às sugestões mais populares.

Importamos solicitações de recursos existentes do GitHub - Pesquise esse problema lá!

E não se preocupe, esse problema ainda existirá no GitHub para o bem da posteridade. Como é uma importação somente de texto da postagem original para o UserVoice, ainda teremos em mente os comentários e a discussão que já existem aqui sobre o problema do GitHub.

O GitHub continuará sendo o canal para relatar bugs.

Mais uma vez, esse problema agora pode ser encontrado pesquisando o título em: https://aws.uservoice.com/forums/598381-aws-command-line-interface

- A equipe de SDKs e ferramentas da AWS

Esta entrada pode ser encontrada especificamente no UserVoice em: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168325-s3-sync-does-not-preserve-permissions-across- Bucke

@ASayre - Este pode ser o lugar errado para ter essa discussão, mas você poderia explicar por que a Amazon desajeitadamente dividiu as discussões no AWS CLI no GitHub e no UserVoice?

As solicitações de recursos parecem adequadas aqui no GitHub. É relativamente fácil filtrar apenas as solicitações de recursos e até mesmo classificar pelas mais populares:

O GitHub também facilita o compartilhamento de trechos de código ou referência a outros problemas (como # 1060, que está relacionado a este), e uma grande parte da base de usuários AWS CLI já está ativa aqui no GitHub.

Com base no feedback da comunidade, decidimos retornar as solicitações de recursos para os problemas do GitHub.

Alguém encontrou uma solução decente para fazer isso? Função muito necessária.

A resposta acima força * a ser lida publicamente. Isso não preserva as permissões.

Qual é o progresso? Eu também encontro esse problema. Agora, apenas uso sync --include / exclude para resolver esse problema.

Alguém quer me pagar para trabalhar nisso?

4 anos e ainda assim este pesadelo continua. Tenho mais de 10 milhões de arquivos e todos com permissões perdidas durante a cópia. Como é possível algo tão simples como manter as permissões acontecer?

+1

Para qualquer outra pessoa que venha aqui, pude usar isso para copiar um intervalo para outro e manter ACLs: https://github.com/cobbzilla/s3s3mirror/tree/2.1-stable

Também é significativamente mais rápido.

Para mim, estou usando o s3 atualmente para fazer backup de minhas pastas de trabalho. Isso inclui git repo's, e meu repo continua pirando depois de todas as mudanças de permissão.

Para mim, a solução acabou sendo encontrar uma forma de redefinir apenas as permissões por repo. Até que a AWS conserte seu lixo, esta é a solução para mim.

git config --global --add alias.permission-reset '!git diff -p -R --no-color | grep -E "^(diff|(old|new) mode)" --color=never | git apply'

Encontrei a solução aqui:

https://stackoverflow.com/questions/2517339/how-to-recover-the-file-permissions-to-what-git-thinks-the-file-should-be

Oi,

Eu encontrei o mesmo problema - eu tinha um balde com toneladas de objetos, enquanto alguns deles deveriam estar acessíveis publicamente. Tive que copiar o intervalo inteiro para outro enquanto preservava as ACLs e, claro, configurar as ACLs manualmente levaria muito tempo.

Fiz este script simples em python que copia os objetos de um intervalo para outro e também configura as ACLs para ele.

Sinta-se livre para dar uma olhada:
https://github.com/terminator9999/aws-s3-bucket-copy/