Préserver les permissions de fichiers et la propriété lors des conversions entre plateformes

La conversion de fichiers est généralement abordée en termes de fidélité du format — la qualité de la conservation du contenu visuel ou textuel après une transformation. Pourtant, pour de nombreuses organisations, l’enveloppe de sécurité qui entoure un fichier — ses permissions, sa propriété et ses attributs étendus — est tout aussi vitale. Lorsqu’un document passe d’un poste de travail Windows à un serveur Linux, ou lorsqu’il transite par un convertisseur basé sur le cloud, ces contrôles d’accès peuvent être silencieusement supprimés, exposant des données sensibles ou rompant des flux de travail automatisés. Ce guide explique les modèles de permissions sous‑jacents, montre pourquoi ils comptent pendant la conversion, et fournit des techniques concrètes et reproductibles pour les garder intacts.

Comprendre les modèles de permissions sur les différentes plateformes

Les permissions POSIX dominent les systèmes de type Unix. Chaque fichier possède un utilisateur propriétaire, un groupe propriétaire, et trois triplets de permissions (lecture, écriture, exécution) pour l’utilisateur, le groupe et les autres. Les distributions Linux modernes supportent également les ACL POSIX, qui permettent des entrées plus fines que le triplet classique.

Les ACL Windows sont plus expressives. Une liste de contrôle d’accès (Access Control List) contient une séquence d’entrées de contrôle d’accès (Access Control Entries, ACE) qui spécifient des règles d’autorisation ou de refus pour des utilisateurs, des groupes ou des principes intégrés comme Authenticated Users. Chaque ACE peut inclure des drapeaux d’héritage, des permissions spécifiques à un type d’objet et des paramètres d’audit.

Les deux plateformes exposent les attributs étendus (xattrs) et les ressources forks (sur macOS) qui stockent des métadonnées personnalisées — par exemple une balise « confidentiel » ou une somme de contrôle utilisée par un système externe. Lorsqu’un fichier est simplement copié, la plupart des systèmes d’exploitation conservent ces attributs ; cependant, la plupart des outils de conversion naïfs traitent le fichier comme un flux d’octets opaque et suppriment tout ce qui dépasse les données brutes.

Pourquoi les permissions comptent dans les flux de conversion

  1. Conformité réglementaire – Le GDPR, HIPAA et d’autres législations exigent souvent que les contrôles d’accès survivent à toute opération de manipulation de données, pas seulement au stockage.
  2. Continuité opérationnelle – Les pipelines automatisés qui s’appuient sur l’exécution basée sur des groupes (par ex. un job nocturne qui traite les fichiers appartenant à data-ingest) échoueront si la propriété est perdue.
  3. Atténuation des risques – Des ACL supprimées peuvent transformer un document privé en un fichier accessible à tous, créant une surface de fuite de données.
  4. Audit – Pour les besoins judiciaires ou d’e‑discovery, l’état original des permissions fait partie de la chaîne de preuve ; son altération peut invalider la piste d’audit.

Par conséquent, tout pipeline de conversion qui déplace des fichiers entre systèmes de fichiers, conteneurs ou services cloud devrait traiter les permissions comme des citoyens de première classe.

Scénarios typiques où les permissions disparaissent

1. Windows → Linux via SMB ou FTP

Quand un fichier est téléversé depuis un partage Windows vers un serveur Linux, le client SMB mappe généralement le propriétaire Windows à un utilisateur local (souvent nobody) et élimine l’ACL d’origine. Le FTP, en tant que protocole en texte clair, supprime toutes les métadonnées.

2. Services de conversion basés sur le cloud

La plupart des convertisseurs SaaS acceptent un POST multipart/form-data, lisent le contenu du fichier, effectuent la transformation et renvoient le résultat. Le service traite la charge utile comme des octets bruts ; ainsi, les bits de permission côté OS ne quittent jamais la machine cliente. Après le téléchargement, le fichier résultant hérite des permissions par défaut du répertoire de destination. Par exemple, en utilisant convertise.app, le document téléversé est entièrement traité dans le cloud, et le fichier retourné arrive avec les permissions du dossier de téléchargement local.

3. Extraction d’archives sans préservation des métadonnées

Un raccourci fréquent consiste à zipper un répertoire, envoyer l’archive, convertir les fichiers à l’intérieur, puis dézipper les résultats. Le format zip peut stocker les permissions Unix, mais de nombreux consommateurs désarchivent avec l’option -X désactivée, ce qui entraîne la perte des bits ; les utilitaires ZIP sous Windows les ignorent entièrement.

Stratégies pour conserver les permissions pendant la conversion

a. Emballer les fichiers dans une archive qui retient les métadonnées

L’approche la plus simple consiste à placer les fichiers sources dans une archive qui enregistre explicitement les données de permission, puis à convertir l’archive elle‑même si possible. Les formats qui le supportent incluent :

  • tar avec l’option --preserve-permissions (-p). tar stocke UID/GID, les bits de mode et les ACL POSIX lorsqu’on ajoute l’option --acls (GNU tar).
  • pax, qui est une archive standard POSIX capable de conserver les attributs étendus.
  • 7‑zip (.7z) qui peut enregistrer les ACL Windows avec le paramètre -sacl.

En conservant l’archive, on évite de devoir réappliquer les permissions après chaque conversion de fichier individuel.

b. Exporter et réimporter les métadonnées de permission séparément

Lorsque le format cible ne peut pas contenir les bits de permission (par ex. conversion d’un DOCX en PDF), exportez les descripteurs de sécurité dans un fichier secondaire avant la conversion :

# Exporter les ACL POSIX vers un fichier JSON
auditctl -a always,exit -F arch=b64 -S chmod,chown -k perm_export
getfacl -R /data/incoming > perms.acl

Après la conversion, un petit script de post‑traitement réapplique les ACL sauvegardées aux nouveaux fichiers, en les faisant correspondre par chemin relatif.

c. Utiliser des outils de conversion qui respectent les métadonnées

Certains utilitaires en ligne de commande offrent des options intégrées pour copier les permissions :

  • pandoc (pour les formats de documents) respecte le drapeau --preserve afin de conserver les bits de mode de fichier.
  • ffmpeg peut copier le drapeau metadata ; bien qu’il ne propage pas les permissions UNIX, on peut le combiner avec -map_metadata pour garder les balises intégrées.
  • Pour la conversion d’images, convert d’ImageMagick possède l’option -strip (qui supprime les métadonnées) mais, par défaut, il laisse le mode de fichier intact. Éviter explicitement -strip et utiliser -set filename:original peut aider à restaurer les permissions plus tard.

d. Réapplication programmable avec des langages de script

Des langages comme Python exposent les API os.chmod, os.chown et os.setxattr. Une routine générique de réapplication pourrait ressembler à :

import json, os, pwd, grp

with open('perms.json') as f:
    perms = json.load(f)

for rel_path, meta in perms.items():
    dst = os.path.join('converted', rel_path)
    os.chmod(dst, meta['mode'])
    uid = pwd.getpwnam(meta['owner']).pw_uid
    gid = grp.getgrnam(meta['group']).gr_gid
    os.chown(dst, uid, gid)
    for attr, value in meta.get('xattrs', {}).items():
        os.setxattr(dst, attr, value.encode())

Stocker les métadonnées dans un format JSON portable signifie que le même script fonctionne sous Windows (via pywin32 pour les ACL) et sous Linux.

Exemple de flux de travail de bout en bout

  1. Collecter les fichiers sources dans /project/source.
  2. Exporter les permissions vers perms.json à l’aide d’un petit utilitaire Go qui parcourt l’arborescence et écrit UID/GID, mode et chaînes SDDL d’ACL Windows.
  3. Créer une tarball avec tar -cvpf source.tar /project/source — l’option -p force l’archive à stocker les bits de mode exacts.
  4. Téléverser l’archive vers le service de conversion (par ex. curl -F file=@source.tar https://api.convertise.app/convert?to=zip). Le service renvoie une nouvelle archive converted.zip où chaque document est transformé mais le conteneur demeure.
  5. Extraire l’archive sur l’hôte de destination avec tar -xvpzf converted.zip (ou 7z x sous Windows avec -sacl).
  6. Réappliquer les ACL en injectant perms.json dans le script Python présenté ci‑dessus.

Le résultat est un ensemble de fichiers convertis qui ressemblent et se comportent exactement comme les originaux du point de vue sécurité.

Tests et vérifications

Après une exécution de conversion, vérifiez que les permissions correspondent aux attentes :

  • Comparaison de sommes de contrôle – Calculez un SHA‑256 pour chaque fichier avant et après conversion afin d’assurer l’intégrité du contenu ; puis comparez des hachages de permissions en utilisant getfacl -c (Linux) ou icacls (Windows) et hachez ces chaînes de sortie.
  • Régression automatisée – Intégrez une étape dans un pipeline CI qui copie un répertoire de fixtures, lance la conversion, et affirme que stat -c "%a %U %G" correspond à la ligne de base.
  • Journaux d’audit – Si votre organisation exige une trace d’audit, enregistrez les horodatages d’exportation et de réapplication des permissions aux côtés des IDs de conversion. Cela satisfait de nombreux cadres de conformité qui demandent la traçabilité des métadonnées de sécurité.

Cas limites et considérations spéciales

Fichiers chiffrés

Lorsqu’un fichier est chiffré au niveau du système de fichiers (BitLocker sous Windows, eCryptfs sous Linux), le service de conversion ne peut pas voir les permissions sous‑jacentes car les données sont présentées sous forme de blob chiffré. La pratique recommandée est de déchiffrer dans une zone de mise en scène sécurisée, effectuer la conversion tout en préservant les ACL, puis rechiffrer le résultat.

Conversions en streaming

Certaines pipelines envoient un fichier directement à un binaire de conversion (ffmpeg -i - -f mp4 -). Dans ces cas, le fichier source n’existe plus sur le disque une fois le flux démarré, et ses bits de permission ne peuvent pas être copiés. La solution de contournement consiste à dupliquer le descripteur de fichier : ouvrez la source, récupérez son mode avec fstat, puis, après la conversion, appliquez le mode sauvegardé au fichier de sortie avec chmod.

Normalisation des chemins inter‑plateformes

Windows utilise les antislashs et peut stocker des chemins insensibles à la casse, tandis que Unix est sensible à la casse. Lors du rapprochement des métadonnées secondaires avec les fichiers convertis, normalisez les chemins avec os.path.normcase (Windows) ou os.path.realpath (POSIX) avant la recherche.

Checklist pour une conversion sûre des permissions

  • Identifier le modèle de permission source (POSIX, ACL Windows, xattr macOS).
  • Exporter les métadonnées de permission vers une représentation portable avant conversion.
  • Choisir un format d’archive qui stocke ces bits si vous devez regrouper les fichiers.
  • Privilégier les outils de conversion qui conservent le mode de fichier, à moins de vouloir supprimer explicitement les métadonnées.
  • Réappliquer les permissions après conversion à l’aide d’une automatisation scriptée.
  • Vérifier à l’aide de tests basés sur des sommes de contrôle que le contenu et les ACL correspondent aux attentes.
  • Documenter le processus dans un run‑book interne pour les auditeurs.

Conclusion

La conversion de fichiers est souvent réduite à la question « le nouveau fichier a‑t‑il le même aspect ? ». Dans des environnements sécurisés et conformes, la réponse doit aussi inclure « le nouveau fichier conserve‑t‑il les mêmes contrôles d’accès ? ». En traitant les permissions comme des données explicites — en les exportant, les transportant aux côtés du payload, et en les réinstaurant après conversion — vous pouvez construire des pipelines qui respectent à la fois la fidélité du contenu et la posture de sécurité. Que vous déplaciez des PDF d’un poste Windows vers un système d’archivage Linux, ou que vous exploitiez un convertisseur cloud‑first tel que convertise.app, ces bonnes pratiques vous offrent des résultats prévisibles, audités et sans sacrifier la commodité des services modernes de conversion de fichiers.