Tag Archives: Permissions

Copier des fichiers d’un bucket S3 d’un compte Amazon à un autre

Aujourd’hui je me suis retrouvé dans un cas assez particulier. Je souhaitais copier l’intégralité d’un bucket Amazon S3 vers un autre bucket sachant que les deux étaient sur deux comptes différents.
Généralement j’utilise l’outil payant CloudBerry S3 Explorer PRO pour parcourir mes différents buckets S3. L’avantage de ce logiciel, qu’il partage avec d’autres d’ailleurs, est qu’il permet de travailler avec plusieurs threads pour démultiplier la vitesse d’exécution. En effet, lors d’une copie par exemple, le logiciel doit copier fichier par fichier et quand la quantité de fichiers devient importante, la latence du réseau et le temps de réponse du serveur ne sont plus négligeables. En utilisant plusieurs threads pour faire la copie, on divise le temps nécessaire pour copier l’ensemble des fichiers.

Une solution simple, mais coûteuse en bande passante (et qui peut donc avoir un impact financier important), reste de copier dans un premier temps les fichiers d’un bucket vers un PC, puis, du PC vers le bucket de destination. Mais cette solution n’est pas la plus efficace. Il existe la possibilité de copier directement des fichiers d’un bucket à l’autre, avec une seule requête S3, et sans gaspiller de la bande passante.

Le problème de cette solution c’est qu’elle renvoie l’erreur Access Denied et que pour le résoudre, il faut mettre en place une règle sur le bucket. Cependant après quelques recherches, j’ai fini par trouver les règles à appliquer.

Dans un premier temps, il faut donner l’accès en lecture au compte propriétaire du bucket de destination aux données du bucket de source. Pour se faire, il va vous falloir récupérer l’AWS Account ID du compte propriétaire du bucket de destination. Il est disponible sur la page Your Security Credentials dans la section Account Identifiers.
Ensuite il faut appliquer la règle suivante sur le bucket source :

{
  "Version": "2008-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:::root"
      },
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::/*",
        "arn:aws:s3:::"
      ],
      "Condition": {}
    }
  ]
}

Quand vous remplacez il faut enlever les – qui séparer chaque groupe de chiffre pour avoir quelque chose qui ressemble à 123456789012.

Voilà qui devrait résoudre vos problèmes.

Tagged , , ,

Cygwin, Permissions are too open

Si comme moi, vous utilisez quotidiennement Windows, que ce soit au travail ou à la maison, vous connaissez surement Cygwin.

Néanmoins pour les curieux voici une très courte description :

Linux-like environment for Windows making it possible to port software running on POSIX systems (such as Linux, BSD, and Unix systems) to Windows.

Bien que rendant d’énormes services, Cygwin n’est pas pour autant parfait. Un de ses points faibles est notamment la gestion des droits pour les fichiers.
Ce billet n’a pas pour vocation de résoudre cette problématique, je ne sais même pas si c’est techniquement faisable étant donné que le système de droit de Windows et d’Unix n’est pas vraiment compatible.

Cependant, je vais vous aider à résoudre un des problèmes qui m’arrivent régulièrement : l’impossibilité de modifier les droits du groupe d’un fichier.

Pour introduire la problématique, je vous donne un exemple concret.

Il existe deux façon de se connecte en SSH à un serveur. La première est d’utiliser le classique couple nom d’utilisateur, mot de passe associé. Cependant, je n’aime pas spécialement cette approche, car elle implique de connaitre les différents mots de passe pour chaque serveur.
J’utilise donc l’autre solution qui consiste à utiliser une clé RSA pour se connecter.

La syntaxe et la suivante :

ssh username@hostname -i private_key_file

Problème, de base les fichiers sur on pour droits 666 avec Cygwin. Et quand on essaie d’utiliser une clé avec ces droits on obtient ce message d’erreur :

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0666 for 'id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: id_rsa

Facile me direz-vous, il suffit de modifier les droits du fichier grâce à chmod. Oui, mais ça ne marche pas :

$ chmod 400 id_rsa
$ ls -l id_rsa
-r--r-----+ 1 Julien Aucun 1766 16 avr.   2012 id_rsa

Eh oui, il n’est pas possible de modifier les droits du groupe pour ce fichier, ils sont toujours identiques aux droits du propriétaire.

Vous remarquerez que le groupe pour ce fichier est Aucun. Le problème est là. Le fichier n’a pas de groupe. Hors, ce n’est pas possible sur un système POSIX, Cygwin pallie donc à ça en créant un groupe nommé Aucun.

La solution consiste à changer le groupe de ce fichier. Pour celà un petit coup d’oeil au fichier /etc/group vous aidera à choisir :

$ cat /etc/group
root:S-1-5-32-544:0:
Système:S-1-5-18:18:
TrustedInstaller:S-1-5-80-956008885-3418522649-1831038044-1853292631-2271478464:4294967294:
Administrateurs:S-1-5-32-544:544:
Administrateurs Hyper-V:S-1-5-32-578:578:
Duplicateurs:S-1-5-32-552:552:
IIS_IUSRS:S-1-5-32-568:568:
Invités:S-1-5-32-546:546:
Lecteurs des journaux d’événements:S-1-5-32-573:573:
Opérateurs d'assistance de contrôle d'accès:S-1-5-32-579:579:
Opérateurs de chiffrement:S-1-5-32-569:569:
Opérateurs de configuration réseau:S-1-5-32-556:556:
Opérateurs de sauvegarde:S-1-5-32-551:551:
Utilisateurs:S-1-5-32-545:545:
Utilisateurs avec pouvoir:S-1-5-32-547:547:
Utilisateurs de gestion à distance:S-1-5-32-580:580:
Utilisateurs de l’Analyseur de performances:S-1-5-32-558:558:
Utilisateurs du Bureau à distance:S-1-5-32-555:555:
Utilisateurs du journal de performances:S-1-5-32-559:559:
Utilisateurs du modèle COM distribué:S-1-5-32-562:562:
HomeUsers:S-1-5-21-1022396269-1448771893-189778280-1002:1002:
WinRMRemoteWMIUsers__:S-1-5-21-1022396269-1448771893-189778280-1000:1000:
Aucun:S-1-5-21-1022396269-1448771893-189778280-513:513:
Julien:S-1-5-21-1022396269-1448771893-189778280-1001:11001:

Parmi les groupes, il y a en autres Utilisateurs. On va se servir de lui:

$ chown :Utilisateurs id_rsa
$ ls -l id_rsa
-r--r-----+ 1 Julien Utilisateurs 1766 16 avr.   2012 id_rsa

Et voilà, il ne reste plus qu’à modifier les droits d’accès pour le groupe et le tour est joué :

$ chmod 400 id_rsa
$ ls -l id_rsa
-r--------+ 1 Julien Utilisateurs 1766 16 avr.   2012 id_rsa
$ ssh me@myserver -i id_rsa
Enter passphrase for key 'id_rsa':
me@myserver:~$

Bienvenue chez vous !

Tagged , , , ,