Pareil pour un socket si ma mémoire est bonne. Les pipes ne sont pas forcément nommés, mais un pipe non nommé serait plus intrusif.
D'un autre côté, je ne vois pas comment exécuter un programme sur un FS sans supporter de FS au préalable, et les gens de systemd ont justement poussé, de mémoire, pour bouger tout /bin et /sbin vers /usr, qui requiert, justement, que /usr soit monté sur /. Si tu peux exécuter un daemon géré par systemd, c'est que systemd a monté les partoches avant. Y compris /dev, qui inclue /dev/shm, qui est un ramdisk.
[edit]
D'ailleurs, le nom attendu dans la variable d'environnement est un fichier, donc oui, clairement, ce point ne change rien comparé à un af_unix tel que fait actuellement. CE point, j'insiste.
[^] # Re: Après une récente vulnérabilité de SSH, Systemd réduit ses dépendances.
Posté par freem . En réponse au lien After a Recent SSH Vulnerability, Systemd Reduces Dependencies. Évalué à 3. Dernière modification le 07 avril 2024 à 15:47.
Pareil pour un socket si ma mémoire est bonne. Les pipes ne sont pas forcément nommés, mais un pipe non nommé serait plus intrusif.
D'un autre côté, je ne vois pas comment exécuter un programme sur un FS sans supporter de FS au préalable, et les gens de systemd ont justement poussé, de mémoire, pour bouger tout /bin et /sbin vers /usr, qui requiert, justement, que /usr soit monté sur /. Si tu peux exécuter un daemon géré par systemd, c'est que systemd a monté les partoches avant. Y compris /dev, qui inclue /dev/shm, qui est un ramdisk.
[edit]
D'ailleurs, le nom attendu dans la variable d'environnement est un fichier, donc oui, clairement, ce point ne change rien comparé à un af_unix tel que fait actuellement. CE point, j'insiste.