Créer un outil de conteneur sans root, avec verrous et téléchargements d’images vérifiés

## Bâtir le cœur avec la seule bibliothèque standard et détecter les hôtes mobiles Conservez l’environnement d’exécution principal sans dépendances tierces et préférez les fonctions natives du langage à l’appel d’un shell pour les requêtes système, les téléchargements, les archives et l’inspection de la plateforme. ### Politique de dépendances - Utilisez la bibliothèque standard pour vérifier les capacités du terminal, obtenir les données des utilisateurs et des groupes, inspecter les binaires, détecter l’architecture, traiter HTTP et manipuler les archives. - Exécutez uniquement l’environnement d’exécution de conteneur nécessaire à l’isolation réelle. - Si cet environnement manque sur un hôte pris en charge, ne proposez son installation que dans un terminal interactif et seulement après l’accord de l’utilisateur. - Lorsque cela convient, exécutez l’environnement en remplaçant le processus actuel plutôt qu’en ajoutant une couche de shell. - Conservez le manifeste du paquet comme source de référence pour la version, avec une solution de repli documentée pour les arborescences de sources non installées. - Acheminez tous les alias de commandes et points d’entrée de console vers une seule fonction principale canonique. ### Détection de la plateforme - Ne détectez un hôte mobile spécialisé que si au moins deux signaux indépendants concordent : indices du système d’exploitation, variables d’environnement dédiées et préfixe de plateforme accessible. - Calculez le résultat une seule fois et utilisez-le de manière cohérente pour les chemins, l’environnement par défaut, les options disponibles, les montages et les extensions de l’environnement d’exécution. - Sur les hôtes ordinaires, appliquez par défaut les conventions standard de répertoires de base, sans montage propre aux appareils mobiles. ## Identifier les conteneurs par le nom de leur dossier et traiter à part les invités spéciaux Traitez l’identité du répertoire, la présence de métadonnées, la migration des anciennes structures et le comportement de l’invité comme des décisions distinctes. ### Modèle de stockage - Utilisez le nom de répertoire validé comme seul identifiant du conteneur. - Stockez le système de fichiers assemblé sous ce répertoire et conservez les métadonnées de l’image dans un manifeste séparé. - Autorisez les installations depuis une archive simple à omettre les métadonnées d’image lorsqu’aucune image de registre n’existe. - Migrez les anciennes structures lors de la première opération qui nécessite la nouvelle structure, puis réécrivez les liens de compatibilité concernés. - Déduisez les emplacements de l’environnement d’exécution, du cache, des conteneurs, des sessions, des couches et des manifestes à partir d’un seul module de chemins tenant compte de la plateforme. - Validez les noms de conteneurs à chaque point d’entrée, y compris les alias dérivés d’images et les noms lus dans des archives. ### Classification de l’invité - Détectez un invité spécialisé au moyen d’une sentinelle qui doit être un fichier, et non un simple chemin existant ; des sessions simultanées peuvent matérialiser les cibles de montage sous forme de répertoires. - Attribuez aux invités spécialisés leurs propres valeurs de base pour le répertoire personnel, le chemin, le préfixe et le répertoire temporaire. - Ne montez jamais les répertoires privés ou le préfixe d’installation de l’application hôte par-dessus un invité qui fournit les siens. - Désactivez la conversion de liens incompatible et les options qui modifient l’identité pour ce type d’invité. - Appliquez les montages facultatifs du système hôte uniquement en dehors des modes isolé et minimal. - Refusez les invités spécialisés d’architecture différente lorsqu’un préfixe partagé permettrait aux binaires de l’hôte de masquer ceux de l’invité. ## Bien répartir les commandes et protéger les écritures par des verrous et des fichiers temporaires L’analyse des commandes et la propriété des verrous doivent rester correctes lors des interruptions, de la réentrance, du remplacement de processus, du détachement et de l’activité simultanée du cache. ### Déroulement de la CLI 1. Acheminez les signaux secondaires de sortie vers le chemin d’interruption normal afin que la progression et les fichiers partiels soient nettoyés de manière cohérente. 2. Avertissez en cas d’exécution avec privilèges élevés sans rendre cet avertissement fatal, et refusez l’invocation imbriquée de l’environnement d’exécution de conteneur. 3. Ne sondez l’environnement d’exécution que pour les commandes qui en ont besoin ; laissez les commandes d’inspection, de processus et propres aux images définir des conditions plus étroites. 4. Interceptez l’aide d’une commande avant de valider les arguments positionnels et refusez les commandes inconnues avant l’analyse générale. 5. Préservez les jetons situés après le délimiteur d’options littéral pour les commandes qui lancent un programme interne. 6. Imposez les arguments requis de manière centralisée, sauf lorsque le mode d’entrée détermine volontairement les exigences. 7. Appliquez le mode silencieux global avant la répartition, tout en préservant la signification propre à chaque commande et en affichant toujours les erreurs et les avertissements. ### Verrous et atomicité - Utilisez des verrous partagés pour les sessions assimilables à des lectures et les sauvegardes, et des verrous exclusifs pour l’installation, la suppression, le renommage, la réinitialisation, la restauration et les écritures dans la destination. - Acquérez plusieurs verrous de conteneurs dans l’ordre résultant du tri de leurs chemins. - Associez les verrous de construction à l’image de sortie et à l’architecture, tout en protégeant les index de cache partagés par leur propre verrou. - Rendez les verrous exclusifs réentrants pour les commandes qui appellent une autre commande modificatrice sur le même conteneur. - Laissez les verrous de session survivre au remplacement de processus et dissociez-les du processus d’origine plutôt que de les déverrouiller lorsqu’un descendant détaché en hérite la propriété. - En cas de conflit de verrou, échouez immédiatement et indiquez son détenteur lorsqu’il peut être identifié. - Toute routine qui écrit dans le cache ou une sentinelle doit créer un fichier temporaire, effectuer ensuite un remplacement atomique et nettoyer lors de toute exception. ## Vérifier les couches d’image téléchargées et protéger les identifiants du registre Considérez les références de registre, l’authentification, les redirections, les empreintes, les couches et les membres d’archives comme hostiles jusqu’à leur validation. ### Récupération et cache - Préférez un cache complet et vérifié pour l’utilisation hors ligne ; lorsque seules des couches manquent, ne récupérez que ces couches. - Calculez le hachage de chaque couche téléchargée pendant son transfert et comparez son empreinte avant de la promouvoir. - Validez la syntaxe de l’empreinte avant de la convertir en chemin de système de fichiers, afin que des références forgées ne puissent pas sortir de la racine du cache. - Refusez les formats de compression que l’implémentation des archives ne peut pas décoder en toute sécurité. - Implémentez les whiteouts opaques et propres à chaque entrée, filtrez les cibles de liens physiques et refusez les traversées de chemins dans les noms des membres. ### Authentification et envoi - Exigez une forme explicite avec nom d’utilisateur et mot de passe avant de transmettre des identifiants Basic à un service de jetons. - Supprimez les en-têtes d’autorisation lors des redirections vers un autre hôte. - Limitez les jetons acquis aux actions de récupération ou d’envoi demandées. - Avant l’envoi, convertissez la configuration stockée dans sa forme canonique et vérifiez son empreinte par rapport au manifeste. - Sondez les blobs distants et n’envoyez que le contenu manquant. - Maintenez hors périmètre les modes d’envoi et les index multiarchitectures non pris en charge au lieu de les approximer. - Présentez les échecs d’autorisation comme des erreurs de permission sans exposer les identifiants. ## Indiquer l’architecture de l’invité et construire de zéro l’environnement du processus enfant Les informations d’architecture et les environnements des processus enfants doivent décrire l’invité sans hériter accidentellement de l’hôte. ### Gestion de l’architecture - Détectez l’architecture d’un invité installé à partir des en-têtes binaires d’exécutables connus. - Normalisez les noms d’architecture natifs, issus du registre et préfixés par la plateforme au moyen d’une seule correspondance. - Ne sélectionnez un émulateur que lorsque l’exécution native est indisponible et ne montez que les chemins système requis par son chargeur. - Indiquez l’architecture de l’invité et l’identité du noyau émulé au lieu de copier la valeur de l’hôte. ### Environnement du processus enfant - Construisez l’environnement du processus enfant à partir d’une table vide et transmettez-le directement au remplacement de processus. - Appliquez délibérément l’ordre de priorité : valeurs de base, variables d’image filtrées, variables de l’hôte autorisées, substitutions de l’utilisateur, variables d’identité, puis variables du terminal. - Appliquez les variables d’image et d’utilisateur dans tous les modes, tout en limitant les variables de l’hôte mobile au mode ordinaire non isolé. - En mode minimal, omettez le chemin de base, les variables d’intégration à l’hôte et l’identité de l’utilisateur, sauf si elles sont explicitement requises. - Validez les noms de variables avant d’écrire un profil de connexion et placez leurs valeurs entre guillemets de manière sûre. - Excluez des profils persistants les variables propres aux sessions, internes à l’environnement d’exécution, du chargeur et d’identité. - Supprimez les variables de préchargement du chargeur avant l’exécution et maintenez les répertoires de compatibilité partagés stables entre les sessions simultanées. ## Lancer les conteneurs en arrière-plan et arrêter tout leur arbre de processus Les opérations d’exécution, de détachement, de terminaison et de construction doivent préserver le comportement du manifeste, la durée des verrous, la portabilité et la propriété des processus. ### Exécution et détachement - Combinez le point d’entrée et les valeurs de commande de l’image conformément à la sémantique des images de conteneur. - Respectez un remplacement explicite du répertoire de travail et utilisez sinon le réglage de l’image ou la racine du système de fichiers. - Résolvez le mode d’aperçu de la commande avant toute branche de détachement. - Détachez l’exécution avec un double fork et une nouvelle session, redirigez les flux standard et enregistrez le processus final de l’environnement d’exécution dans le processus petit-enfant. - Transmettez l’identifiant du processus final au premier plan et laissez le descendant détaché conserver le verrou hérité du conteneur. ### Terminaison et constructions sûres - Ne déterminez les cibles de terminaison qu’à partir du registre des sessions actives. - Terminez l’arbre complet des descendants, et non uniquement le processus racine de l’environnement d’exécution. - Construisez une table des processus parents résistante aux cycles, n’envoyez jamais de signal au processus actuel ni aux identifiants de processus critiques pour le système et vérifiez l’exécutable du processus racine avant de parcourir l’arbre. - Utilisez par défaut un signal de terminaison ordonnée et autorisez un remplacement explicite par nom ou numéro. - Analysez les étapes de construction et les arguments globaux avant l’exécution, validez les cibles au plus tôt et répartissez les opérations de métadonnées, d’exécution, de copie et d’ajout entre des gestionnaires dédiés. - Exécutez les étapes de construction de manière isolée et non interactive, sauf si un here-document fournit l’entrée. - Associez les entrées du cache de construction à l’état parent, à l’instruction et aux entrées supplémentaires pertinentes ; verrouillez les mises à jour de l’index du cache. - Excluez les métadonnées de compatibilité de l’environnement d’exécution des instantanés portables de couches tout en préservant le contenu du fichier référencé. ## Sauvegarder et restaurer les conteneurs en refusant les entrées d’archive dangereuses Les archives et la sortie du terminal franchissent des limites de confiance et ne doivent altérer ni l’état du conteneur ni les invites interactives. ### Sauvegarde et restauration - Stockez chaque conteneur sous une racine d’archive unique contenant des métadonnées facultatives et l’arborescence du système de fichiers. - Rendez les sous-arborescences illisibles accessibles pour la sauvegarde, filtrez les périphériques et les points de terminaison de communication, puis normalisez les métadonnées de propriété. - Refusez d’envoyer une archive binaire vers un terminal interactif, sauf si une destination de sortie explicite est fournie. - Détectez la compression à partir des données de l’archive et des formats standard, y compris pour une entrée diffusée. - Réenracinez les anciennes structures d’archive dans la structure actuelle du conteneur. - Refusez les membres vides, ceux du répertoire courant ou parent et ceux dont le nom de conteneur est invalide. - Acquérez le verrou de destination et n’effacez un système de fichiers existant que lorsque le premier membre valide de ce conteneur est prêt à être restauré. ### Intégration du terminal et des commandes - Suspendez les écritures informatives du terminal lorsqu’une invite de mot de passe ou de plein écran d’un processus frère contrôle l’écho ou le mode canonique du terminal. - Conservez le contenu de l’aide sous forme de données et affichez-le de manière adaptative dans les limites de largeur documentées. - Enregistrez chaque nouvelle commande dans la répartition, les métadonnées d’analyse, les arguments requis, les données d’aide et les tables d’alias. - Préservez l’en-tête de licence du paquet et les conventions de nommage dans chaque nouveau fichier source.