buffer or not buffer

Le 23/11/2011 16:18, Hugues a écrit :

Ce cher Herve Autret <autret@lussinan.org> a posté :

Cette ressource n'est pas dissimulée (ce n'est pas comme si elle
s'appelait /dev/.shm par ex.), pas plus que /tmp, je ne vois pas de
raison de prendre des précautions quant à son emploi

Pas plus que je ne vois pas pourquoi tu devrais prendre des précautions
quant à écrire n'importe quoi dans /boot, /usr/bin, /var, tant qu'à
faire :-)

Tiens, je te recopie un passage de mon message précédent, puisqu'il
s'accorde parfaitement avec ta 'réflexion' :

Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root,
ce qui change tout au problème énoncé ici, puisque 'normalement'
lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du
système.

--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !

SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !

Nicolas George :

[] vire .Xauthority, un fichier au nom abscons dont 99% des
utilisateurs n'ont jamais entendu parler, l'effet saute moins aux yeux.

Quoique ...
No protocol specified
No protocol specified
No protocol specified
No protocol specified
xterm Xt error: Can't open display: machine:0.0

Cette ressource n'est pas dissimulée

Il y a plein de choses dissimulées : essaie de passer /dev/mem en mode
0666 puis d'écrire dedans qu'on rigole.

La liste des conneries à ne pas faire si on veut que ça marche est
infinie, ce n'est pas la question.

Oui et non. Se renseigner, c'est poster « à quoi sert ce répertoire
bizarre, /dev/shm, que j'ai sur mon système », pas écrire dedans comme
ça sans réfléchir.

Nicolas, à quoi sert selon toi ce répertoire /dev/shm, que j'ai sur mon
système ? Par quel mécanisme le fait qu'un simple utilisateur écrive
dedans peut-il empêcher un programe de fonctionner quelque temps plus
tard ?
--
Hervé

Herve Autret , dans le message <4ecd2dc5$0$20627$426a74cc@news.free.fr>,
a écrit :

Nicolas, à quoi sert selon toi ce répertoire /dev/shm, que j'ai sur mon
système ?

Il sert à la libc pour implémenter les zones de mémoire partagées POSIX. Il
doit donc être accessible aux applications utilisateurs, mais son usage doit
être réservé aux accès qui utilisent l'API idoine, à savoir shm_open et
cousins.

Par quel mécanisme le fait qu'un simple utilisateur écrive
dedans peut-il empêcher un programe de fonctionner quelque temps plus
tard ?

Dans la mesure où l'utilisation qui est faite de ce répertoire ne fait pas
partie de l'interface publique de la libc, on peut soupçonner que la seule
présence d'un fichier avec un nom malencontreux peut perturber le
fonctionnement des fonctions concernées.

NiKo , dans le message <4ecd298d$0$24961$426a34cc@news.free.fr>, a
écrit :

Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root,
ce qui change tout au problème énoncé ici, puisque 'normalement'
lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du
système.

Et comme je l'ai indiqué par ailleurs, il y a plein de fichiers appartenant
à l'utilisateur qui, s'ils sont manipulés de manière inconsidérée, rendront
le fonctionnement du système pour cet utilisateur hasardeux. On tourne en
rond.

Je stocke mon cache Firefox, mes répertoires .adobe et .macromedia et
d'autres cochoncetés qui, de mon point de vue, n'ont pas à être
persistants sur ma machine.

Eh bien c'est complètement idiot. Encore plus que si tu décidais, par on ne
sait quelle lubie, de les stocker dans /var/lock, qui, si tu regardes bien,
est aussi en 1777.

Et je n'ai encore jamais vu de plantages,
bugs où quoi que ce soit dans le style de ce que tu décris.

Eh bien tu as eu de la chance.

Et je te cite deux passages :

[...] If you compare it to ramfs (which was the template to create
tmpfs) you gain swapping and limit checking. Another similar thing is
the RAM disk (/dev/ram*), which simulates a fixed size hard disk in
physical RAM, where you have to create an ordinary filesystem on top.
Ramdisks cannot swap and you do not have the possibility to resize them.
[...]

[...] 3) Some people (including me) find it very convenient to mount it
e.g. on /tmp and /var/tmp and have a big swap partition. And now loop
mounts of tmpfs files do work, so mkinitrd shipped by most distributions
should succeed with a tmpfs /tmp. [...]

Tiré, tout de même, juste de la documentation du kernel.

<http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt>

Tiens, on dirait le P4nd4 : tu cites sans comprendre. Je détaille :

Lorsqu'il compare /dev/shm et /dev/ram, il ne dit nulle part qu'il ne
faut pas l'utiliser comme un système de fichiers ordinaire.

À aucun moment il ne compare /dev/shm avec /dev/ram : relis le passage que
tu as cité, à aucun moment il n'est question de /dev/shm. Ce dont il est
question, c'est tmpfs, ce paragraphe compare un ramdisk avec un certain type
de système de fichiers appelé tmpfs, sans préjuger de l'usage qui en est
fait.

Le deuxième paragraphe est encore plus détaillé : il suggère d'utiliser
tmpfs pour le répertoire /tmp, et c'est une excellente idée, que
personnellement je suis depuis plus de huit ans (en revanche, c'est une
moins bonne idée pour /var/tmp, parce que /var/tmp est censé être plus
pérenne que /tmp).

En revanche, il n'est à aucun moment question de /dev/shm.

Je n'ai encore pas vu de distribution Linux où un utilisateur pouvait
écrire dans un répertoire alors que, pour des raisons obscures que toi
seul semble connaitre, il ne faudrait pas.

C'est juste parce que tu n'as pas bien regardé : /var/lock est en écriture
publique, et pourtant y créer un fichier avec un nom bien choisi peut
empêcher certains logiciels de fonctionner, en particulier ceux liés aux
modems.

Bizarrement, tout fonctionne comme si je n'avais rien fait ! La seule
différence se trouve dans le graphe d'utilisation de la RAM qui me
montre que la moitié de celle ci est utilisée.

Et qu'as-tu fait entre temps ? Les applications qui peuvent être perturbées
par du contenu imprévu sans /dev/shm sont très rares, parce que c'est une
API peu utilisé. Ton exemple ne prouve strictement rien.

Le 23/11/2011 18:54, Nicolas George a écrit :

NiKo , dans le message <4ecd298d$0$24961$426a34cc@news.free.fr>, a
écrit :

Sauf qu'un simple utilisateur ne peut pas faire ça. Il faut être root,
ce qui change tout au problème énoncé ici, puisque 'normalement'
lorsqu'on est root, on fait un peu plus attention à ce que l'on fait du
système.

Et comme je l'ai indiqué par ailleurs, il y a plein de fichiers appartenant
à l'utilisateur qui, s'ils sont manipulés de manière inconsidérée, rendront
le fonctionnement du système pour cet utilisateur hasardeux. On tourne en
rond.

Je stocke mon cache Firefox, mes répertoires .adobe et .macromedia et
d'autres cochoncetés qui, de mon point de vue, n'ont pas à être
persistants sur ma machine.

Eh bien c'est complètement idiot. Encore plus que si tu décidais, par on ne
sait quelle lubie, de les stocker dans /var/lock, qui, si tu regardes bien,
est aussi en 1777.

Mais pourquoi donc cela (autre que - parce que tu l'as dit) serait
complètement idiot ?

Pourrais tu avancer des docs la dessus, plutôt que camper sur tes
positions ?

Et je n'ai encore jamais vu de plantages,
bugs où quoi que ce soit dans le style de ce que tu décris.

Eh bien tu as eu de la chance.

Et je te cite deux passages :

[...] If you compare it to ramfs (which was the template to create
tmpfs) you gain swapping and limit checking. Another similar thing is
the RAM disk (/dev/ram*), which simulates a fixed size hard disk in
physical RAM, where you have to create an ordinary filesystem on top.
Ramdisks cannot swap and you do not have the possibility to resize them.
[...]

[...] 3) Some people (including me) find it very convenient to mount it
e.g. on /tmp and /var/tmp and have a big swap partition. And now loop
mounts of tmpfs files do work, so mkinitrd shipped by most distributions
should succeed with a tmpfs /tmp. [...]

Tiré, tout de même, juste de la documentation du kernel.

<http://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt>

Tiens, on dirait le P4nd4 : tu cites sans comprendre. Je détaille :

Merci de ne pas troller ici. Pour cela il y a FCOLD.

Lorsqu'il compare /dev/shm et /dev/ram, il ne dit nulle part qu'il ne
faut pas l'utiliser comme un système de fichiers ordinaire.

À aucun moment il ne compare /dev/shm avec /dev/ram : relis le passage que
tu as cité, à aucun moment il n'est question de /dev/shm. Ce dont il est
question, c'est tmpfs, ce paragraphe compare un ramdisk avec un certain type
de système de fichiers appelé tmpfs, sans préjuger de l'usage qui en est
fait.

[...] 2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
POSIX shared memory [...]

Donc, si je comprends bien, glibc attends que tmpfs sois monté sur
/dev/shm, mais selon toi, il n'y aurait aucun rapport entre tmpfs et
/dev/shm ...

Le deuxième paragraphe est encore plus détaillé : il suggère d'utiliser
tmpfs pour le répertoire /tmp, et c'est une excellente idée, que
personnellement je suis depuis plus de huit ans (en revanche, c'est une
moins bonne idée pour /var/tmp, parce que /var/tmp est censé être plus
pérenne que /tmp).

En revanche, il n'est à aucun moment question de /dev/shm.

Donc, puisque tmpfs est monté sur /dev/shm, et que /tmp utilise tmpfs,
tu ne vois toujours aucun lien entre /dev/shm et tmpfs ?

Quand on trouve dans un /etc/fstab :

tmpfs /dev/shm tmpfs defaults 0 0

Tu ne vois toujours aucun lien entre /dev/shm et tmpfs ?

Je n'ai encore pas vu de distribution Linux où un utilisateur pouvait
écrire dans un répertoire alors que, pour des raisons obscures que toi
seul semble connaitre, il ne faudrait pas.

C'est juste parce que tu n'as pas bien regardé : /var/lock est en écriture
publique, et pourtant y créer un fichier avec un nom bien choisi peut
empêcher certains logiciels de fonctionner, en particulier ceux liés aux
modems.

Tu nous fais une pirouette ? Maintenant il ne faut plus écrire
"n'importe quoi" mais "un fichier avec un nom bien choisi". On s'éloigne
de ton affirmation originelle que je te rappelle :

** Quand tu vois un répertoire dont tu ne connais pas l'usage, tu te dis
qu'on peut y écrire n'importe quoi n'importe comment ? **

Bizarrement, tout fonctionne comme si je n'avais rien fait ! La seule
différence se trouve dans le graphe d'utilisation de la RAM qui me
montre que la moitié de celle ci est utilisée.

Et qu'as-tu fait entre temps ? Les applications qui peuvent être perturbées
par du contenu imprévu sans /dev/shm sont très rares, parce que c'est une
API peu utilisé. Ton exemple ne prouve strictement rien.

Tout comme tes affirmations qui ne prouvent rien non plus, et pour
lesquelles une doc (si possible issue de ceux qui ont développé tmpfs
... Ouups pardon ... /dev/shm) appuyant tes dires serait la bienvenue.

--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !

SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !

Nicolas George :

Nicolas, à quoi sert selon toi ce répertoire /dev/shm, que j'ai sur mon
système ?

Il sert à la libc pour implémenter les zones de mémoire partagées POSIX.
Il doit donc être accessible aux applications utilisateurs, mais son
usage doit être réservé aux accès qui utilisent l'API idoine, à savoir
shm_open et cousins.

Là, comme ça, je dirais : pas de risque. shm_open ouvre un fichier de la
même manière que open:
The operation of shm_open() is analogous to that of open(2)
Note que quand je parle d'écrire des fichiers dans /dev/shm, il est
entendu pour moi que c'est en user depuis le shell et que /dev/shm dest
monté en tmpfs (sinon, je ne vois pas ce qu'un user pourrait faire).
Lorsqu'on monte /dev/shm avec le type tmpfs et qu'on y crée ensuite des
fichiers, je pense que le système de fichiers de type tmpfs appelle la
primitive idoine.
D'après menuconfig, c'est dans Kconfig ; ça ne passe pas par un fs
externe :

Symbol: DEVTMPFS[=y]
Type : boolean
Prompt: Maintain a devtmpfs filesystem to mount at /dev
Defined at drivers/base/Kconfig:19
Depends on: HOTPLUG [=y]
Location:
-> Device Drivers
-> Generic Driver Options

Par quel mécanisme le fait qu'un simple utilisateur écrive
dedans peut-il empêcher un programe de fonctionner quelque temps plus
tard ?

Dans la mesure où l'utilisation qui est faite de ce répertoire ne fait
pas partie de l'interface publique de la libc,

Lorsque l'utilisateur crée un fichier dasn /dev/shm, la libc fait des
appels au noyau via tmpfs pour créer le fichier et il n'y a donc pas de
passe-droit.

on peut soupçonner que la seule présence d'un fichier avec un nom
malencontreux peut perturber le fonctionnement des fonctions concernées.

Qu'il y ait conflit de noms, c'est toujours possible ; comme dans /tmp .
Un programmeur concerné par la sécurité de son application peut aussi
utiliser shmget () plutôt que shm_open() : pas de conflit avec les
fichiers.

S'il doit malgré tout utiliser des fichiers dans /dev/shm, il peut encore
créer des arborescences pour limiter les conflits (cf. /tmp et /var).
Peu de chance qu'il subsiste des problèmes récurrents liés à /dev/shm
sans qu'on sache un jour d'où ils viennent.

Hors application de la loi de Murphy (car un jour ou l'autre...)
--
Hervé

NiKo , dans le message <4ecd3c83$0$20434$426a74cc@news.free.fr>, a
écrit :

Mais pourquoi donc cela (autre que - parce que tu l'as dit) serait
complètement idiot ?

J'ai expliqué dans un autre message la fonction technique de /dev/shm. Ça
non plus tu n'as pas réussi à le lire.

Merci de ne pas troller ici. Pour cela il y a FCOLD.

Je ne trolle pas, je souligne que tu as cité un texte sans le comprendre.

[...] 2) glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
POSIX shared memory [...]

Cette ligne est mal formulée, et du coup elle devient essentiellement
fausse. Ce qu'il devrait y avoir, c'est ceci :

# [...] 2) glibc 2.2 and above expects an instance of tmpfs to be mounted at
# /dev/shm for POSIX shared memory [...]

Donc, si je comprends bien, glibc attends que tmpfs sois monté sur
/dev/shm, mais selon toi, il n'y aurait aucun rapport entre tmpfs et
/dev/shm ...

Je n'ai pas dit qu'il n'y avait aucun rapport, apprends à lire.

Donc, puisque tmpfs est monté sur /dev/shm, et que /tmp utilise tmpfs,
tu ne vois toujours aucun lien entre /dev/shm et tmpfs ?

Je n'ai pas dit qu'il n'y avait aucun lien (bis). En revanche, il n'y a
aucun lien entre le tmpfs monté dans /tmp et que tu peux utiliser à ta guise
et le tmpfs monté dans /dev/shm et qu'il faut laisser à l'usage privé de la
glibc.

En fait, je pense que c'est ça que tu n'as pas compris, et qui ruine
l'ensemble de ton discours : tmpfs, c'est un type de système de fichiers, au
même titre qu'ext4 ou vfat : à chaque fois qu'on en monte un, c'en est un
différent, avec des fichiers totalement indépendants. Ce n'est pas comme
procfs ou sysfs, qui donnent la même vue quel que soit l'endroit où on le
monte.

tmpfs est dans le noyau pour fournir un service : un répertoire où des
fichiers temporaires peuvent être stockés de manière efficace. La libc a
besoin de ce service, et pour ça elle demande qu'un tel répertoire soit
instancié dans /dev/shm. Si tu as besoin du même service, tu dois créer ta
propre instance dans un répertoire différent, tu ne dois pas aller taper
dans celui de la libc, parce que tu n'as aucune idée de ce qu'elle peut
vouloir en faire.

Tu nous fais une pirouette ? Maintenant il ne faut plus écrire
"n'importe quoi" mais "un fichier avec un nom bien choisi".

Un fichier avec un nom bien choisi est un cas particulier de n'importe quoi.
Quelque chose que tu peux faire exprès, tu peux aussi le faire par accident
en ayant un gros coup de malchance.

Tout comme tes affirmations qui ne prouvent rien non plus, et pour
lesquelles une doc (si possible issue de ceux qui ont développé tmpfs
... Ouups pardon ... /dev/shm) appuyant tes dires serait la bienvenue.

Ma référence est le code source de la glibc. Tu peux le consulter assez
facilement sur le web. Le fichier à visiter est
sysdeps/unix/sysv/linux/shm_open.c. Manque de chance, il semblerait que
personne n'ait pris la peine de vulgariser ce que fait cette fonction de
manière à ce que quelqu'un de ton niveau de compétence puisse le comprendre.

Enfin, si, quelqu'un l'a fait : moi-même, quelques messages plus tôt. Mais
évidemment, ça ne va pas te convenir.

Le 23/11/2011 19:57, Nicolas George a écrit :

Ma référence est le code source de la glibc. Tu peux le consulter assez
facilement sur le web. Le fichier à visiter est
sysdeps/unix/sysv/linux/shm_open.c. Manque de chance, il semblerait que
personne n'ait pris la peine de vulgariser ce que fait cette fonction de

Pas besoin, il suffit de lire le code, et voila ce qu'elle fait :

177 fd = open (fname, oflag | O_NOFOLLOW, mode);

Ah ben zut, en fait shm_open ferait en fait un vulgaire "open" ...

manière à ce que quelqu'un de ton niveau de compétence puisse le comprendre.

Malheureusement :

1) Tu ne sais rien de mon niveau. Mais venant de ta part, cela ne
m'étonne pas vraiment.

2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm
pour ses objets mémoire partagés, je ne vois pas dans le code le moindre
avertissement signalant qu'il ne faut absolument pas qu'un utilisateur
place des fichiers dans /dev/shm !

42 /* This is the default directory. */
43 static const char defaultdir[] = "/dev/shm/";

56 where_is_shmfs (void)
68 /* It is in the normal place. */
69 mountpoint.dir = (char *) defaultdir;
70 mountpoint.dirlen = sizeof (defaultdir) - 1;
71
72 return;

75 /* OK, do it the hard way. Look through the /proc/mounts file and if
76 this does not exist through /etc/fstab to find the mount point. */

[... etc ...]

3) Sont vraiment nuls les développeurs du noyau et les développeurs
GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à
un utilisateur standard du système alors que Monsieur Nicolas George
SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...

4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs
? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?

5) Il serait temps que tu comprennes la philosophie Unix ... Le système
n'est pas fait pour qu'un utilisateur ne puisse pas casser SA propre
session, mais pour qu'un utilisateur ne puisse casser celle des AUTRES
ainsi que le SYSTÈME complet.

--
Le mode sans échec de Windows est la preuve que son
mode normal est un échec !

SONY : It only does everything ... until we remove !
PS3 Firmware update 3.21 :
The first software update which downgrade !

NiKo , dans le message <4ecd4c08$0$24216$426a34cc@news.free.fr>, a
écrit :

Pas besoin, il suffit de lire le code, et voila ce qu'elle fait :
177 fd = open (fname, oflag | O_NOFOLLOW, mode);
Ah ben zut, en fait shm_open ferait en fait un vulgaire "open" ...

Je n'ai pas prétendu le contraire. Tu noteras cependant qu'elle ne cherche
absolument pas à se prémunir contre l'existence de fichiers de même nom (je
te laisse le soin de chercher dans la doc d'open comment elle aurait dû
faire).

1) Tu ne sais rien de mon niveau.

Ça fait quelques années que je lis des messages de toi ici et sur fcold.

2) Excepté que la GLIBC utilise de préférence le répertoire /dev/shm
pour ses objets mémoire partagés, je ne vois pas dans le code le moindre
avertissement signalant qu'il ne faut absolument pas qu'un utilisateur
place des fichiers dans /dev/shm !

Parce que tu t'attends à trouver des avertissements destinés aux
utilisateurs dans le code source d'une bibliothèque ?

3) Sont vraiment nuls les développeurs du noyau et les développeurs
GNU/Linux en général ! Laisser un accès en écriture sur un répertoire à
un utilisateur standard du système alors que Monsieur Nicolas George
SAIT qu'il ne faut absolument rien mettre dans ce répertoire ...

Je n'ai pas dit ça, apprends à lire.

4) Et comment fait un utilisateur pour se créer une 'instance' de tmpfs
? Comment ? J'entends au fond de la salle qu'il faut qu'il soit root ?

Il ne fait pas. L'utilisateur qui veut créer des fichiers et répertoires
temporaires les met dans /tmp, c'est fait pour ça. S'il est attentif, il
peut éventuellement remarquer que /tmp est une instance de tmpfs et se
réjouir d'avoir un administrateur compétent, mais ça s'arrête là.

5) Il serait temps que tu comprennes la philosophie Unix ...

Là, tu es franchement ridicule.

Herve Autret , dans le message <4ecd4044$0$24177$426a74cc@news.free.fr>,
a écrit :

Là, comme ça, je dirais : pas de risque. shm_open ouvre un fichier de la
même manière que open:
The operation of shm_open() is analogous to that of open(2)

Cette phrase ne dit pas ce que tu crois qu'elle veut dire et que tu
expliques juste au dessus.

Cette phrase est tirée de la page de man de shm_open, qui décrit l'usage de
la fonction du point de vue d'une personne programmant une application, et
affirme que ça s'utilise de manière similaire à open, ce qui est vrai.

Elle ne décrit pas du tout comment est implémenté shm_open en interne, et de
fait, différents Unix utilisent des méthodes radicalement différentes. Il se
trouve que sous GNU/Linux, shm_open est implémenté par l'ouverture d'un
fichier dans /dev/shm, mais rien dans la documentation publique destinée aux
utilisateurs et programmeurs d'application ne documente la correspondance
entre l'argument donné à shm_open et le nom de fichier sous /dev/shm, ni
même le fait qu'il n'y aurait qu'un seul fichier, et pas, par exemple, un
fichier pour les données proprement dites et un fichier auxiliaire de
description.

Note que quand je parle d'écrire des fichiers dans /dev/shm, il est
entendu pour moi que c'est en user depuis le shell et que /dev/shm dest
monté en tmpfs (sinon, je ne vois pas ce qu'un user pourrait faire).
Lorsqu'on monte /dev/shm avec le type tmpfs et qu'on y crée ensuite des
fichiers, je pense que le système de fichiers de type tmpfs appelle la
primitive idoine.

Oui, mais pas dans le sens que tu crois. La création d'un fichier dans
/dev/shm invoque les fonctions du noyau qui gèrent les tmpfs, évidemment,
mais ces fonctions n'ont aucune connaissance des fonctions de la libc qui
utilisent habituellement ce répertoire : la libc, de leur point de vue,
n'est qu'une bibliothèque parmi d'autres.

Du coup, tu cours le risque d'entrer en conflit avec ce que la libc s'attend
à trouver dans ce répertoire, puisque tu modifies son contenu sans passer
par les fonctions idoines.

En fait, ce que tu te proposes de faire, c'est exactement comme si tu
décidais d'ouvrir .mozilla/firefox/*/places.sqlite dans un éditeur de texte
et de le modifier ainsi : rien ne t'en empêchera, mais il y a toutes les
chances qu'à l'issue de l'opération le fichier soit inutilisable, parce que
la bibliothèque qui le manipule habituellement, sqlite, s'attends à ce qu'il
ait une structure très précise.

Le problème n'est pas aussi critique avec /dev/shm, parce que les exigences
de la glibc sur sa structure sont assez relâchées, et surtout parce que très
peu d'applications s'en servent, mais il est exactement de même nature.

D'après menuconfig, c'est dans Kconfig ; ça ne passe pas par un fs
externe :

Symbol: DEVTMPFS[=y]
Type : boolean
Prompt: Maintain a devtmpfs filesystem to mount at /dev
Defined at drivers/base/Kconfig:19
Depends on: HOTPLUG [=y]
Location:
-> Device Drivers
-> Generic Driver Options

Tu devrais lire plus attentivement la description de cette option, tu
verrais qu'elle n'a qu'un lien très ténu avec la discussion, et en
particulier qu'elle n'est pas liée à tmpfs, malgré ce que le nom semble
indiquer.

Lorsque l'utilisateur crée un fichier dasn /dev/shm, la libc fait des
appels au noyau via tmpfs pour créer le fichier et il n'y a donc pas de
passe-droit.

Je ne vois pas pourquoi tu parles de passe-droit. Cf. mon exemple avec
sqlite, ou l'autre plus bas sur ~/.fontconfig pour ce point.

Qu'il y ait conflit de noms, c'est toujours possible ; comme dans /tmp .

La différence, c'est que l'usage de /dev/shm est normalement réservé à la
glibc, ce qui lui permet de prendre des mesures pour gérer les conflits de
noms harmonieusement. De ce point de vue, c'est comme un programme ou une
bibliothèque qui crée un répertoire dans $HOME, disons ~/.fontconfig : si tu
t'amuses à y créer des fichiers à la main, ne viens pas te plaindre si les
applications qui ont besoin de polices se mettent à bugger.

Un programmeur concerné par la sécurité de son application peut aussi
utiliser shmget () plutôt que shm_open() : pas de conflit avec les
fichiers.

Certainement pas. Tous les problèmes soulevés par les API d'IPC POSIX sont
également soulevés, souvent en pire, par leur équivalent SysV, avec en plus
des problèmes qui leur sont propres.

S'il doit malgré tout utiliser des fichiers dans /dev/shm, il peut encore
créer des arborescences pour limiter les conflits (cf. /tmp et /var).

Non, il ne doit pas créer des fichiers dans /dev/shm, pas plus qu'il ne doit
créer des fichiers dans /var/lock ou ~/.fontconfig. S'il veut créer des
fichiers temporaires, il les crée dans /tmp.