• # mkstemp / mkdtemp

    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 26 octobre 2024 à 15:52.

    Intéressant, je ne connaissais pas ces fonctions.

    En shell, j'utilise la var dollar-dollar qui n'est pas prédictible facilement, sauf si un virus est déjà à l'écoute des process (dans ce cas, $$ est le moindre des problèmes).

    J'avoue que c'est pour éviter les collisions que j'utilise $$ , pas pour une histoire de prédictibilité.

    Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

    • [^] # Re: mkstemp / mkdtemp

      Posté par  . Évalué à 4 (+3/-0). Dernière modification le 26 octobre 2024 à 17:08.

      Tu devrais (re)lire la doc. C'est une façon de faire assez ancienne et peu sûre.

      Si tu vraiment besoin de fichier temporaire utilise mktemp qui est sécurisé.

      • [^] # Re: mkstemp / mkdtemp

        Posté par  . Évalué à 3 (+1/-0). Dernière modification le 26 octobre 2024 à 19:40.

        Les arguments avancés contre $$ sont en général (j'ai fait une recherche pour ne pas en oublier):

        1) Incohérences et collisions : Si un script utilise $$ pour nommer un fichier temporaire, chaque exécution aura un nom de fichier différent (car le PID change pour chaque exécution). Cela peut provoquer des incohérences si le script s'attend à retrouver ce fichier par la suite.

        -> je n'utilise pas $$ directement , je le stocke dans une variable temporaire.

        2) Sécurité et vulnérabilité aux attaques : Utiliser $$ dans le nom de fichier peut rendre le script vulnérable aux attaques par liens symboliques. Un attaquant peut deviner le PID du processus et créer un lien symbolique pointant vers Dieu sait quoi.

        -> il est vrai, mais mktemp ne protégera pas davantage (voir plus loin)

        3) Problèmes de nettoyage : Si le script ne se termine pas correctement, le fichier temporaire créé avec $$ pourrait rester sur le disque. En cas de redémarrage ou de nouvelle exécution du script, un fichier temporaire précédent pourrait être confondu avec celui de la nouvelle exécution, surtout si le PID se reproduit après un certain temps.

        -> j'efface toujours $TMP en sortie. Si par le plus grand des hasards mon script plantait, était relancé et que j'avais fait un tour du compteur des PID pour retomber sur le même nom de fichier (si j'arrive à ça, je crois que je vais tenter un loto), ma première écriture dans le fichier va le tronquer si il existait déjà (la première écriture est une redirection simple avec > ).

        Maintenant, voyons le cas de mktemp qui est censé compliquer la vie de l'attaquant et être « plus sécurisé ».

        Voici un script shell qui ne fait pas grand chose, à part créer un fichier temporaire et passer ensuite son temps à d'obscurs traitements inclusifs.

        #!/bin/bash

TMP=$(mktemp)
echo $TMP
for((;;)) do sleep 1; printf '·'; done

        Ce qui donne:

        coriseth tmp  /tmp$ ./mktemp.sh 
/tmp/tmp.Qbx9OP740h
···········

        Mais pendant ce temps …

        /tmp$ ps -p $(pgrep mktemp.sh) -o lstart=
Sat Oct 26 19:08:19 2024

/tmp$ ls -l /tmp | grep 19:08
   0 -rw------- 1 jseb jseb    0 26-10-24 19:08 tmp.Qbx9OP740h

        Et voilà.

        Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

        • [^] # Re: mkstemp / mkdtemp

          Posté par  . Évalué à 4 (+4/-0). Dernière modification le 26 octobre 2024 à 20:00.

          La sécurité ne repose pas sur le secret du nom du fichier, mais sur l'appel système open : avec les bons paramètres le noyau DOIT créer le fichier, et REFUSE d'ouvrir un fichier existant. C'est la mécanique qui garantit que le propriétaire du fichier est bien celui de l'appelant.

          PS : cette mécanique est utile en programmation pure Unix pour implémenter un mutex entre processus.

          • [^] # Re: mkstemp / mkdtemp

            Posté par  . Évalué à 3 (+1/-0).

            Ok mais en quoi cela protège t-il d'une attaque par substitution ?

            Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr

            • [^] # Re: mkstemp / mkdtemp

              Posté par  . Évalué à 3 (+3/-0).

              L'attaquant ne peut pas prendre les droits sur le fichier. Soit il les avait parce qu'il a créé lui-même le fichier : alors l'appel à `open échoue. Soit tu obtiens les droits et là il ne peut plus les prendre (c'est l'objectif du sticky bit dans le cas d'un répertoire partagé).

              Le nom aléatoire c'est juste pour éviter les collisions. Ça joue, mais plus à la marge sur la sécurité.

      • [^] # Re: mkstemp / mkdtemp

        Posté par  (site web personnel) . Évalué à 3 (+1/-0).

        Si tu vraiment besoin de fichier temporaire utilise mktemp qui est sécurisé.

        Clairement pas, c'est le meilleur moyen de faire un TOCTOU. En plus la fonction a été retiré de POSIX.

        git is great because linus did it, mercurial is better because he didn't

        • [^] # Re: mkstemp / mkdtemp

          Posté par  . Évalué à 4 (+2/-0).

          Dans le contexte je pense qu'il est clair qu'il parle de la commande mktempd(1) et pas de la fonction mktempd(3).

          La commande n'a pas besoin de la fonction pour exister, elle peut utiliser mkdtemp(3) ou un simple open avec O_CREAT | O_EXCL.

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: mkstemp / mkdtemp

            Posté par  . Évalué à 2 (+1/-0).

            Effectivement il s'agit de la commande mktemp des outils GNU. C'est expliqué dans l'article et j'ai donné le lien vers la doc GNU.

  • # Petite précision

    Posté par  . Évalué à 4 (+4/-0).

    $TMPDIR est une variable d'environnement. Elle contient le chemin d'un répertoire persistant, comme son nom ne l'indique pas, pour des fichiers de travail.

    Si, et seulement si, elle n'est pas valorisée alors faute de mieux les fonctions mk*temp doivent se rabattre sur /tmp. Fondamentalement c'est un fallback.

    Conclusions : valorisez $TMPDIR vers un espace privé. Problème réglé.

    Dans le même ordre d'idée j'ai jamais trop bien compris la politique des distros avec le umask.

    • [^] # Re: Petite précision

      Posté par  . Évalué à 3 (+2/-0).

      Tout à fait et merci pour les explications complémentaires.

      À ma connaissance dans les distributions actuelles les variables $TMPDIR ou $TEMP ne sont pas défnies. Beaucoup d'outils vont utiliser par défaut /tmp (et aussi /var/tmp pour systemd).

      Pour les scripts il peut être pertinent d'utiliser $XDG_RUNTIME_DIR (/run/user/$UID) qui est un répertoire accessible uniquement à l'utilisateur, monté en tmpfs.

      • [^] # Re: Petite précision

        Posté par  (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 28 octobre 2024 à 11:45.

        À ma connaissance dans les distributions actuelles les variables $TMPDIR ou $TEMP ne sont pas défnies. Beaucoup d'outils vont utiliser par défaut /tmp (et aussi /var/tmp pour systemd).

        C'est justement pour que les utilisateurs ou les programmes les choisissent, que ce soit ~/tmp, ~/.local/tmp, ~/.local/var/appname/tmp ou autre…

  • # Il y a quand même un truc qui me fait bondir dans son commentaire

    Posté par  . Évalué à 7 (+5/-0).

    ** We can’t remove sticky bit support from the kernel** as long as there’s a global /tmp, even if it is sometimes hidden by an overlay.

    Pourquoi veut-il faire ça ? Le sticky bit sur un répertoire est très utile, utilisé ailleurs et bien suffisant dans beaucoup de cas d'utilisation. De plus il me semble que si on supprime le support du sticky bit dans Linux, celui-ci ne serait plus posix compatible.

  • # Et la taille

    Posté par  . Évalué à 2 (+1/-1).

    Il me semble bien que souvent, la partition/tmp est plus petite qu'une tique et plus volatile que l'ether1. Des logiciels comme Blender (un merveilleux logiciel de 3D libre ❤️) ou Nuke (un logiciel de compositing propriétaire 🥺) par exemple, s'en servent pour l'enregistrement automatique des scènes ouvertes. Sauf qu'une scène Blender ou Nuke, ça peut être assez volumineux, et donc peut saturer le /tmp rapidement.

    Si on ajoute que la solution vite-faite-mal-faite-mais-efficace à cette saturation qui provoque des problèmes est le reboot de la machine, et bien les fichiers de sauvegardes automatiques sont perdus2.

    Magique non ?

    1. toute ressemblance avec une balade en forêt serait fortuite ↩

    2. pure fiction 😅 ↩

    • [^] # Re: Et la taille

      Posté par  (site web personnel) . Évalué à 4 (+3/-0).

      Cela se paramètre: aussi bien pour la taille de /tmp que pour le répertoire de destination dans blender (fichiers temporaire, autosaves, ..).

      https://docs.blender.org/manual/en/latest/advanced/blender_directory_layout.html#temp-dir

      Pour ce genre de logiciel et de besoin on peut prendre le temps de configurer sa machine selon ses besoins !

      Cela évite aussi que, par défaut, chaque logiciel commence à écrire ses fichiers temporaires un peu partout sur le disque avec comme conséquence de devoir gérer la persistance de ces fichiers dans chaque application.

    • [^] # Re: Et la taille

      Posté par  . Évalué à 3 (+2/-0). Dernière modification le 28 octobre 2024 à 09:55.

      La plupart du temps il n'y a pas de partition dédiée pour /tmp. Et si elle existe c'est un choix réfléchi de l'utilisateur. Le montage sur disque ou en tmpfs est aussi un choix délibéré de l'utilisateur. Donc c'est un faux problème.

      Au cas où, c'est bien pour cela que les logiciels devraient utiliser $XDG_RUNTIME_DIR pour stocker leurs fichiers temporaires. C'est d'ailleurs ce qu'ils font en général.

      • [^] # Re: Et la taille

        Posté par  (site web personnel) . Évalué à 5 (+2/-0).

        La plupart du temps il n'y a pas de partition dédiée pour /tmp. Et si elle existe c'est un choix réfléchi de l'utilisateur.

        La plupart des distributions montent /tmp en tmpfs depuis plusieurs années.
        Pour des raisons de performances mais aussi s'assurer qu'il est bien vite après un redémarrage.

        • [^] # Re: Et la taille

          Posté par  . Évalué à 3 (+1/-0).

          Ça fait un paquet de temps que j'ai pas installé une distribution, mais j'avais surtout vu des installations de deamon qui nettoient /tmp pour s'assurer qu'il est vidé malgrès des gros uptime (sur serveur comme sur machine de bureau à coup d'hibernation).

          https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

          • [^] # Re: Et la taille

            Posté par  (site web personnel) . Évalué à 2 (+0/-0).

            Ça fait un paquet de temps que j'ai pas installé une distribution, mais j'avais surtout vu des installations de deamon qui nettoient /tmp pour s'assurer qu'il est vidé malgré des gros uptime

            moui ça c'est sur les debian-like, ça ne nettoie que les fichiers pas en cours d'utilisation par un processus (à coup de lsof iirc), c'est ce que je préfère et un /tmp qui a tout l'espace de / aussi (çaÿ bienTM ).

            sur Mageia, /tmp c'est un tmpfs depuis — pfiou —le début je dirais :-) comme chez Fedora je crois. Bon, après chez Mageia nous gardons des trucs historique genre le groupe wheel pour avoir le sudo ou le groupe dialout pour utiliser l'usb pour téléverser sur un arduino par exemple, paye ta cohérence :p ya aussi la séparation / (limité à 50 Go ce qui est absurde vu que task-games est plus gros) et /home (le reste du disque), bon ça se change à l'install' lors du partitionnement mais parfois j'oublie et je laisse la conf' par défaut qui me convient moins :/

            • [^] # Re: Et la taille

              Posté par  . Évalué à 2 (+0/-0).

              moui ça c'est sur les debian-like, ça ne nettoie que les fichiers pas en cours d'utilisation par un processus (à coup de lsof iirc), c'est ce que je préfère et un /tmp qui a tout l'espace de / aussi (çaÿ bienTM ).

              Je trouve, personnellement que c'est toujours une mauvaise idée `/tmp/ en tmpfs (mais je pense que le nommage de ce FS c'est pas bon). Le cache disque fait très bien son travail sans t'exploser la mémoire. tmpfs est très bien pour créer des ramdisk pour des usages particulier (je le combine par exemple avec overlayfs personnellement).

              sur Mageia, /tmp c'est un tmpfs depuis — pfiou —le début je dirais :-) comme chez Fedora je crois. Bon, après chez Mageia nous gardons des trucs historique genre le groupe wheel pour avoir le sudo ou le groupe dialout pour utiliser l'usb pour téléverser sur un arduino par exemple, paye ta cohérence :p ya aussi la séparation / (limité à 50 Go ce qui est absurde vu que task-games est plus gros) et /home (le reste du disque), bon ça se change à l'install' lors du partitionnement mais parfois j'oublie et je laisse la conf' par défaut qui me convient moins :/

              Je trouve assez fou qu'après des décennies, la gestion de volumes ne soit pas le standard (par llvm, btrfs ou autre). Ce n'est pas si compliqué et j'ai l'impression que c'est moins répandu uniquement parce que ce n'est pas l'option préconisée par défaut par les distributions (et donc que moins de gens en parle, qu'il y a moins de tuto/billet de blog/page de wiki, que les gens ne font pas des UI ou des scripts pour, etc).

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

              • [^] # Re: Et la taille

                Posté par  (Mastodon) . Évalué à 3 (+0/-0).

                la gestion de volumes ne soit pas le standard

                Lequel? Le FHS définie la hiérarchie des répertoires mais pas quel répertoire est monté dans quel filesystem et pour beaucoup de choses (comme pour /tmp et /var/tmp) elle ne fait que des recommendations non strictes sur certains points, comme par exemple pour quand effacer des fichiers sur ces deux répertoires.

                Et après bon les standards c'est bien, mais c'est aussi très limitant. À quoi bon avoir des distributions différentes si c'est pour avoir exactement la même chose partout?

                • [^] # Re: Et la taille

                  Posté par  . Évalué à 2 (+0/-0).

                  Le standard dans le sens ce qui est appliqué par défaut pas dans le sens ISO/IETF&co

                  À quoi bon avoir des distributions différentes si c'est pour avoir exactement la même chose partout?

                  Oui mais là je critique l'inverse. Je ne connais aucune distribution qui fasse de LVM ou btrfs avec volume son modèle par défaut d'installation. Tout ce que j'ai pu essayer, c'était dans les paramètres avancés ce qui defacto réduit énormément l'utilisation.

                  https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                  • [^] # Re: Et la taille

                    Posté par  (site web personnel) . Évalué à 3 (+0/-0).

                    Fedora fait ça pourtant depuis débuts.

                    • [^] # Re: Et la taille

                      Posté par  . Évalué à 2 (+0/-0).

                      De ce que je vois effectivement c'est dispo via blivet depuis Fedora 26 et l'option "partitionnement automatique" a bien l'air de faire du LVM. Je ne me souviens pas avoir vu ça dans Fedora Core à l'époque où j'essayais pleins de distributions.

                      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

                      • [^] # Re: Et la taille

                        Posté par  (site web personnel) . Évalué à 3 (+0/-0).

                        Peut être pas dès la 1ère version mais c'était disponible bien tôt, je pense même à l'époque de Fedora Core.

                        C'était d'ailleurs une spécificité de Fedora qui donnait mal à la tête à certains utilisateurs, en particuliers débutants car les ressources à ce sujet étaient plus rares et cette couche d'abstraction ajoutait des difficultés de compréhension et de manipulation.

      • [^] # Re: Et la taille

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 02 novembre 2024 à 19:12.

        Si son problème est que /tmp est trop petit, utiliser XDG_RUNTIME_DIR qui est un tmpfs, le problème sera encore pire non ? Un tmpfs est limité par la taille de RAM+SWAP, ce qui fait que non seulement ça sera petit, mais en plus ça causera un OOM.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.