Posté par jseb .
É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
Posté par jseb .
É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.
Posté par Nicolas .
É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.
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é.
$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.
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.
Posté par Psychofox (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…
** 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.
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 ?
toute ressemblance avec une balade en forêt serait fortuite ↩
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.
Posté par Voltairine .
É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.
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.
Ç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).
Ç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 :/
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).
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?
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.
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.
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.
Posté par Octabrain .
É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.
# mkstemp / mkdtemp
Posté par jseb . É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 Voltairine . É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 jseb . É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.
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.
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.
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.
Ce qui donne:
Mais pendant ce temps …
Et voilà.
Discussions en français sur la création de jeux videos : IRC libera / #gamedev-fr
[^] # Re: mkstemp / mkdtemp
Posté par Nicolas . É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 jseb . É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 Nicolas . É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 David Demelier (site web personnel) . Évalué à 3 (+1/-0).
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 barmic 🦦 . É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 fonctionmktempd(3).La commande n'a pas besoin de la fonction pour exister, elle peut utiliser
mkdtemp(3)ou un simple open avecO_CREAT | O_EXCL.https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: mkstemp / mkdtemp
Posté par Voltairine . É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 Nicolas . É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 Voltairine . É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 Psychofox (Mastodon) . Évalué à 4 (+1/-0). Dernière modification le 28 octobre 2024 à 11:45.
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 totof2000 . Évalué à 7 (+5/-0).
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.
[^] # Re: Il y a quand même un truc qui me fait bondir dans son commentaire
Posté par Luc-Skywalker . Évalué à 5 (+3/-0).
En plus, ça m'a pris des années et des années pour comprendre, à peu près, comment ça marche et à quoi ça sert.
"Si tous les cons volaient, il ferait nuit" F. Dard
# Et la taille
Posté par cg . Évalué à 2 (+1/-1).
Il me semble bien que souvent, la partition
/tmpest 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 ?
toute ressemblance avec une balade en forêt serait fortuite ↩
pure fiction 😅 ↩
[^] # Re: Et la taille
Posté par Jérôme FIX (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 Voltairine . É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 Renault (site web personnel) . Évalué à 5 (+2/-0).
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 barmic 🦦 . É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 BAud (site web personnel) . É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
lsofiirc), c'est ce que je préfère et un/tmpqui a tout l'espace de/aussi (çaÿ bienTM ).sur Mageia,
/tmpc'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 lesudoou 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 barmic 🦦 . Évalué à 2 (+0/-0).
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).
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 Psychofox (Mastodon) . Évalué à 3 (+0/-0).
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 barmic 🦦 . Évalué à 2 (+0/-0).
Le standard dans le sens ce qui est appliqué par défaut pas dans le sens ISO/IETF&co
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 Renault (site web personnel) . Évalué à 3 (+0/-0).
Fedora fait ça pourtant depuis débuts.
[^] # Re: Et la taille
Posté par barmic 🦦 . É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 Renault (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 Octabrain . É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.