Aws-cli: La sincronización s3 no conserva los permisos en los depósitos.

¿Todos los archivos tienen los mismos permisos? Porque por ahora puede ejecutar el comando sync con --acl para establecer los permisos. Sin embargo, la ejecución del comando sync actualmente sin otros argumentos opcionales no busca permisos y se asegura de que, cuando el objeto se transfiera, tenga los mismos permisos que el objeto original. Tendríamos que agregar un argumento / característica adicional para manejarlo.

No, si todos los archivos tuvieran los mismos permisos, podría usar la marca --acl.

Esta función es realmente imprescindible en un mecanismo de sincronización, especialmente cuando tiene miles de archivos con diferentes permisos y desea una verdadera sincronización entre depósitos, no solo una copia de los archivos.

¿Conoce otra forma de obtener permisos por archivo, para que pueda escribir esto con bastante facilidad?

Gracias por ayudar.

Sí, si ejecuta un aws s3api get-object-acl en cada uno de los objetos. Podría contraer acl. Aquí están los documentos del comando.
http://docs.aws.amazon.com/cli/latest/reference/s3api/get-object-acl.html

De acuerdo, gracias, funcionará, pero esta característica aún sería muy apreciada en la sincronización, si no es por defecto, el indicador --preserve-s3-acl estaría bien.

No hay problema. Considerará la característica. Creo que la razón por la que no se ha implementado es porque la operación en sí puede ser costosa. Para determinar los objetos en un depósito s3, se realiza una llamada a ListObjects sin embargo, esto no devuelve los acls para cada objeto. A su vez, tendríamos que volver atrás y ejecutar un GetObjectAcl en cada objeto de la lista, lo que podría llevar un tiempo si hay miles de elementos en el depósito.

Como me tomó un tiempo descubrir que los permisos no estaban sincronizados, tal vez actualizando la documentación de la sincronización de s3 a s3 para mencionar que solo los datos, no los permisos, están sincronizados, ahorraría tiempo a otra persona en el futuro.

Gracias de nuevo

alguna actualización sobre esto?

Agregué una solicitud de extracción (# 1535) para abordar esto (también otras transferencias de S3 a S3, como copy ) hace unas semanas. ¿Alguna posibilidad de que se considere su inclusión?

Hola, sé que es un hilo antiguo, pero lo solucionamos mediante una sincronización por tipo de permiso. En pocas palabras: puede filtrar su sincronización por nombre de clave con --exclude e --include, también puede especificar la ACL de cada sincronización ... Entonces, si tiene un patrón de claves con el que necesita establecer diferentes permisos, ejecute comando de sincronización muchas veces que necesita con diferentes opciones de ACL. Está lejos de ser ideal, ¡pero funciona!

¿Alguna idea del equipo de AWS?

Estoy enviando mis repositorios de git a S3 solo para copias de seguridad. Y luego, cuando los sincronizo, todo tipo de permisos han cambiado.

Todos mis archivos bin ejecutables ya no son ejecutables, y git status chilla al respecto.

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1

+1, Sí, tenía mis depósitos nombrados con un punto, tuve que cambiar para ser compatible con https a través del frente de la nube. Sincronizado con nuevos depósitos con el nombre correcto. No puedo acceder a los archivos. Lea acerca de los permisos. Existen permisos de nivel de objeto. No hay comando para cambiar todos los permisos a nivel de objeto en un depósito. Preguntándose cómo proceder. Los permisos a través de la GUI de aws se ven realmente iguales en ambos depósitos, pero cuando busco la Lista de control de acceso a través del cli, veo que el depósito original tenía un beneficiario adicional que no se copió.
{
"Beneficiario": {
"Tipo": "Grupo",
"URI": " http://acs.amazonaws.com/groups/global/AllUsers "
},
"Permiso": "LEER"
}

¡Buenos días!

Cerramos este problema aquí en GitHub, como parte de nuestra migración a UserVoice para solicitudes de funciones relacionadas con la AWS CLI.

Esto nos permitirá ofrecerle las funciones más importantes, al facilitar la búsqueda y mostrar soporte para las funciones que más le interesan, sin diluir la conversación con informes de errores.

Como introducción rápida a UserVoice (si no está familiarizado): después de que se publica una idea, la gente puede votar sobre las ideas y el equipo de producto responderá directamente a las sugerencias más populares.

Hemos importado solicitudes de funciones existentes desde GitHub: busque este problema allí.

Y no se preocupe, este problema seguirá existiendo en GitHub por el bien de la posteridad. Como es una importación de solo texto de la publicación original en UserVoice, seguiremos teniendo en cuenta los comentarios y la discusión que ya existen aquí sobre el problema de GitHub.

GitHub seguirá siendo el canal para informar errores.

Una vez más, este problema ahora se puede encontrar buscando el título en: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-El equipo de herramientas y SDK de AWS

Esta entrada se puede encontrar específicamente en UserVoice en: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168325-s3-sync-does-not-preserve-permissions-across- cubeta

@ASayre : este podría ser el lugar equivocado para tener esta discusión, pero ¿podría explicar por qué Amazon ha dividido torpemente las discusiones sobre la AWS CLI entre GitHub y UserVoice?

Las solicitudes de funciones parecen apropiadas aquí en GitHub. Es relativamente fácil filtrar solo las solicitudes de funciones e incluso ordenar por las más populares:

GitHub también facilita compartir fragmentos de código o hacer referencia a otros problemas (como el número 1060, que está relacionado con este), y una gran parte de la base de usuarios de la AWS CLI ya está activa aquí en GitHub.

Según los comentarios de la comunidad, hemos decidido devolver las solicitudes de funciones a los problemas de GitHub.

¿A alguien se le ocurrió una solución decente para hacer esto? Función muy necesaria.

La respuesta anterior obliga a * a ser de lectura pública. Eso no conserva los permisos.

¿Cuál es el progreso? También me encuentro con este problema. Ahora solo uso sync --include / exclude para resolver este problema.

¿Alguien quiere pagarme por trabajar en esto?

4 años y sin embargo esta pesadilla continúa. Tengo más de 10 millones de archivos y todos con permisos perdidos durante la copia. ¿Cómo es posible que ocurra algo tan simple como mantener los permisos?

+1

Para cualquier otra persona que venga aquí, pude usar esto para copiar un depósito a otro y mantener las ACL: https://github.com/cobbzilla/s3s3mirror/tree/2.1-stable

También es significativamente más rápido.

Para mí, estoy usando s3 actualmente para hacer una copia de seguridad de mis carpetas de trabajo. Estos incluyen los repositorios de git, y mis repositorios siguen enloqueciendo después de todos los cambios de permisos.

Para mí, la solución terminó siendo encontrar una manera de restablecer solo los permisos por repositorio. Hasta que AWS solucione su basura, esta es la solución para mí.

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

Encontré la solución aquí:

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

Hola,

Encontré el mismo problema: tenía un cubo con toneladas de objetos, mientras que algunos de ellos deberían ser de acceso público. Tuve que copiar todo el depósito en otro mientras conservaba las ACL y, por supuesto, configurar las ACL manualmente me llevaría mucho tiempo.

Hice esta secuencia de comandos simple en Python que copia los objetos de un depósito a otro y también configura las ACL para ello.

Siéntete libre de echar un vistazo:
https://github.com/terminator9999/aws-s3-bucket-copy/