Le débat va un peu plus loin cette fois ci. Ce qui se joue c'est un changement sur la façon dont les logiciels peuvent obtenir l'accès exclusif à un fichier ou un périphérique. Par exemple, un port série: si plusieurs applications ouvrent un tel port, elles vont recevoir chacune la moitié des données.
La méthode classique est de créer un fichier dans /var/lock avec un nom choisi à l'avance t communeavec les autres logiciels qui pourraient avoir accès à la même reesource. Bien sûr ça n'est pas du tout vérifié par le système. Si un logiciel ne suit pas ce protocole, ou bien s'il l'implémente mal, on a un conflit d'accès à la ressource.
Le nouveau système est l'utilisation d'APIs dédiées (flock() par exemple. Il a l'avantage d'être explicitement lié au fichier concerné puisque il n'y a pas besoin d'un fichier séparé dans /var/lock. Et le noyau peut vérifier la orésence d'un lock et interdire l'accès au fichier à d'autres logiciels. systemd souhaite bien sûr utiliser cette nouvelle méthode, et ils ont choisi de forcer la main aux autres logiciels pour se mettre à jour rapidement en bloquant l'ancienne, car il n'est pas souhaitable de faire fonctionner les deux en parallèle (cela obligerait chaque logiciel à implémenter les deux méthodes à la fois avec de nouvelles possipilités de bugs).
Il est probable qu'une future version de FHS changera les règles pour /var/lock (de la même façon que /usr est en train de disparaître par exemple). Systemd est juste allé un petit peu vite.
[^] # Re: Borg
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Debian TC Overrules systemd Maintainers on /var/lock Permissions. Évalué à 10.
Le débat va un peu plus loin cette fois ci. Ce qui se joue c'est un changement sur la façon dont les logiciels peuvent obtenir l'accès exclusif à un fichier ou un périphérique. Par exemple, un port série: si plusieurs applications ouvrent un tel port, elles vont recevoir chacune la moitié des données.
La méthode classique est de créer un fichier dans /var/lock avec un nom choisi à l'avance t communeavec les autres logiciels qui pourraient avoir accès à la même reesource. Bien sûr ça n'est pas du tout vérifié par le système. Si un logiciel ne suit pas ce protocole, ou bien s'il l'implémente mal, on a un conflit d'accès à la ressource.
Le nouveau système est l'utilisation d'APIs dédiées (flock() par exemple. Il a l'avantage d'être explicitement lié au fichier concerné puisque il n'y a pas besoin d'un fichier séparé dans /var/lock. Et le noyau peut vérifier la orésence d'un lock et interdire l'accès au fichier à d'autres logiciels. systemd souhaite bien sûr utiliser cette nouvelle méthode, et ils ont choisi de forcer la main aux autres logiciels pour se mettre à jour rapidement en bloquant l'ancienne, car il n'est pas souhaitable de faire fonctionner les deux en parallèle (cela obligerait chaque logiciel à implémenter les deux méthodes à la fois avec de nouvelles possipilités de bugs).
Il est probable qu'une future version de FHS changera les règles pour /var/lock (de la même façon que /usr est en train de disparaître par exemple). Systemd est juste allé un petit peu vite.