Les user/group IDs dynamique, ça permet d'installer/lancer un service, et s'assurer que quand ce service est stoppé/désinstallé, le système soit redevenu comme avant, à part éventuellement les data et les logs.
Si pour lancer un service, ce service a besoin de créer un utilisateur ou un groupe, quand le service est stoppé il faut que l'utilisateur/groupe soit retiré. Pour avoir un système sans état (stateless). Les UID/GID fixes font partie de l'état.
Donc en gros l'idée c'est d'installer son OS, que l'image de cet OS soit read-only, qu'il y ait toujours moyen de revenir à cet état (factory reset), et que pour lancer des services, ces services créent (temporairement) l'état qu'ils ont besoin. Quand un "service portable" est stoppé/désinstallé, systemd s'assurera de faire un revert de tout l'état qu'a modifié ce service (en gardant les données à ne pas supprimer, bien entendu).
Et un "service portable" sera portable du fait que ça fonctionnera sur n'importe quelle distribution Linux (avec une version suffisamment récente du noyau et de systemd). C'est un container, mais mieux intégré au système (moins isolé). C'est une solution plus sécurisée, pour remplacer les super privileged containers.
[^] # Re: Vivement 'dredi
Posté par Sébastien Wilmet (site web personnel, Mastodon) . En réponse au journal Vidéos de la systemd.conf. Évalué à 5.
Les user/group IDs dynamique, ça permet d'installer/lancer un service, et s'assurer que quand ce service est stoppé/désinstallé, le système soit redevenu comme avant, à part éventuellement les data et les logs.
Si pour lancer un service, ce service a besoin de créer un utilisateur ou un groupe, quand le service est stoppé il faut que l'utilisateur/groupe soit retiré. Pour avoir un système sans état (stateless). Les UID/GID fixes font partie de l'état.
Donc en gros l'idée c'est d'installer son OS, que l'image de cet OS soit read-only, qu'il y ait toujours moyen de revenir à cet état (factory reset), et que pour lancer des services, ces services créent (temporairement) l'état qu'ils ont besoin. Quand un "service portable" est stoppé/désinstallé, systemd s'assurera de faire un revert de tout l'état qu'a modifié ce service (en gardant les données à ne pas supprimer, bien entendu).
Et un "service portable" sera portable du fait que ça fonctionnera sur n'importe quelle distribution Linux (avec une version suffisamment récente du noyau et de systemd). C'est un container, mais mieux intégré au système (moins isolé). C'est une solution plus sécurisée, pour remplacer les super privileged containers.