Ho, t'aurais pas du me lancer là-dessus : donc maintenant on a systemd dans l'initrd (!), une réinvention des user/group Unix avec un langage de définition tout nouveau et du contenu en JSON, l'intégration future de ce dernier bidule à sssd et LDAP, les homes dont on parlait, et du multi-instance pour le gestionnaire afin de palier à ses perf merdiques (que j'ai déjà constaté pour de vrai). Bon, je n'ai extrait que les trucs qui me déplaisent, il n'y a pas que ça, mais c'est un beau florilège je trouve.
Déjà, comme Lennart l'a expliqué au FOSDEM cette année (j'y étais à sa conférence) : systemd fourni ce service mais tout est documenté pour qu'un autre système puisse l'implémenter sans problèmes.
Ensuite, plutôt que de cracher dessus car c'est nouveau et ça bouscule les habitudes, il faudrait se montrer un poil plus constructif quand même. Non pas que la solution de Lennart soit parfaite, complète, impossible à améliorer. Je suis sûr qu'on peut faire mieux en un sens. Mais il a soulevé des problèmes gênants qui ne sont pas solubles à l'ancienne. Il est donc forcément nécessaire de faire un changement plus profond. Donc rejeter tout en bloc comme ça, ça fait vraiment résistance au changement.
Surtout qu'ici on parle d'une nouveauté qui est optionnelle. Pas tout le monde ne peut et ne doit se servir de ce truc avec systemd. Uniquement si cela répond au cas d'usage identifié.
Il ne faut pas se leurrer, les bases d'UNIX sont anciennes et ont peu évolué alors que l'informatique a lui radicalement changé. C'est déjà super que UNIX dans son ensemble puisse fonctionner sur des ordinateurs modernes, mais on en identifie aussi ses manquements, ses choix dans l'architecture qui sont un frein à certains usages nouveaux et pertinents dans notre monde actuel en fait. Réinventer UNIX n'est pas une insulte. D'ailleurs je le rappelle que ses fondateurs ont préféré concevoir son successeur à part (Plan 9) plutôt que de faire une évolution incrémentale car le changement à opérer était trop lourd.
En gros l'idée du nouveau /home est d'être plus portable. Tu peux stocker ton /home/ sur une clé USB ou un disque dur et tu peux l'utiliser facilement partout. Sans recourir à beaucoup d'administration. Donc forcément il faut ajouter une abstraction et des informations annexes au dossier _/home en lui même pour que cela fonctionne. D'où la config en JSON, d'où la refonte de l'UID/GID.
Ensuite il y a des bizarreries dans l'approche actuelle. Par exemple, si tu chiffres ton disque dur, tu tapes un mot de passe pour déchiffrer la partition. Ensuite tu tapes un autre mot de passe pour t'identifier comme simple utilisateur.
En quoi ce cheminement pourtant commun aujourd'hui est problématique ? Déjà, beaucoup de postes sont des portables mono-utilisateurs, avoir des mots de passe potentiellement différents pour déchiffrer et s'identifier est ridicule. L'identification doit faire valoir d'opération de déchiffrement, si tu peux te connecter, tu dois pouvoir déchiffrer tes données, c'est la logique même.
Ensuite, dans le cas d'un système multiutilisateur, cela signifie que celui qui peut déchiffrer la partition peut lire les données des autres utilisateurs en travaillant un peu. Ce n'est pas normal qu'un utilisateur qui déchiffre la partition déchiffre les données de tout le monde en même temps.
Enfin, la partition étant déchiffrée, elle l'est tant que la machine est allumée. Pourtant il pourrait être intéressant que quand l'écran est verrouillé car tu t'éloignes un peu temporairement, tes données soient chiffrés en ton absence. Ce n'est pas réalisable actuellement sans éteindre la machine ou sans se déconnecter totalement. L'identification devant faire office de déchiffrement, cela découle naturellement d'implémenter cela ainsi.
Alors peut être qu'il y a à redire sur l'implémentation sur certains points, il y a d'ailleurs des détails à régler il le sait. Mais son idée est intéressante (je vais sans doute essayer d'y passer) et non réalisable sans effectuer ce genre de changements profonds. Et cela n'a rien d'obligatoire, si cela ne t'intéresse pas, tu ne l'utilises pas. Le but n'est pas de tout remplacer mais d'améliorer un cas d'usage qui est pour le moment non gérable.
Et forcément pour faire ça, oui il faut du bout de code et de config dans l'initrd car le disque dur est chiffré, oui des données doivent être stockées ailleurs par rapport à nos habitudes, etc. Mais il n'y a pas d'autre choix, en fait.
[^] # Re: Et Poettering ?
Posté par Renault (site web personnel) . En réponse au journal Confinement : risque de release de nombreux projets inutiles. Évalué à 10.
Déjà, comme Lennart l'a expliqué au FOSDEM cette année (j'y étais à sa conférence) : systemd fourni ce service mais tout est documenté pour qu'un autre système puisse l'implémenter sans problèmes.
Ensuite, plutôt que de cracher dessus car c'est nouveau et ça bouscule les habitudes, il faudrait se montrer un poil plus constructif quand même. Non pas que la solution de Lennart soit parfaite, complète, impossible à améliorer. Je suis sûr qu'on peut faire mieux en un sens. Mais il a soulevé des problèmes gênants qui ne sont pas solubles à l'ancienne. Il est donc forcément nécessaire de faire un changement plus profond. Donc rejeter tout en bloc comme ça, ça fait vraiment résistance au changement.
Surtout qu'ici on parle d'une nouveauté qui est optionnelle. Pas tout le monde ne peut et ne doit se servir de ce truc avec systemd. Uniquement si cela répond au cas d'usage identifié.
Il ne faut pas se leurrer, les bases d'UNIX sont anciennes et ont peu évolué alors que l'informatique a lui radicalement changé. C'est déjà super que UNIX dans son ensemble puisse fonctionner sur des ordinateurs modernes, mais on en identifie aussi ses manquements, ses choix dans l'architecture qui sont un frein à certains usages nouveaux et pertinents dans notre monde actuel en fait. Réinventer UNIX n'est pas une insulte. D'ailleurs je le rappelle que ses fondateurs ont préféré concevoir son successeur à part (Plan 9) plutôt que de faire une évolution incrémentale car le changement à opérer était trop lourd.
En gros l'idée du nouveau /home est d'être plus portable. Tu peux stocker ton /home/ sur une clé USB ou un disque dur et tu peux l'utiliser facilement partout. Sans recourir à beaucoup d'administration. Donc forcément il faut ajouter une abstraction et des informations annexes au dossier _/home en lui même pour que cela fonctionne. D'où la config en JSON, d'où la refonte de l'UID/GID.
Ensuite il y a des bizarreries dans l'approche actuelle. Par exemple, si tu chiffres ton disque dur, tu tapes un mot de passe pour déchiffrer la partition. Ensuite tu tapes un autre mot de passe pour t'identifier comme simple utilisateur.
En quoi ce cheminement pourtant commun aujourd'hui est problématique ? Déjà, beaucoup de postes sont des portables mono-utilisateurs, avoir des mots de passe potentiellement différents pour déchiffrer et s'identifier est ridicule. L'identification doit faire valoir d'opération de déchiffrement, si tu peux te connecter, tu dois pouvoir déchiffrer tes données, c'est la logique même.
Ensuite, dans le cas d'un système multiutilisateur, cela signifie que celui qui peut déchiffrer la partition peut lire les données des autres utilisateurs en travaillant un peu. Ce n'est pas normal qu'un utilisateur qui déchiffre la partition déchiffre les données de tout le monde en même temps.
Enfin, la partition étant déchiffrée, elle l'est tant que la machine est allumée. Pourtant il pourrait être intéressant que quand l'écran est verrouillé car tu t'éloignes un peu temporairement, tes données soient chiffrés en ton absence. Ce n'est pas réalisable actuellement sans éteindre la machine ou sans se déconnecter totalement. L'identification devant faire office de déchiffrement, cela découle naturellement d'implémenter cela ainsi.
Alors peut être qu'il y a à redire sur l'implémentation sur certains points, il y a d'ailleurs des détails à régler il le sait. Mais son idée est intéressante (je vais sans doute essayer d'y passer) et non réalisable sans effectuer ce genre de changements profonds. Et cela n'a rien d'obligatoire, si cela ne t'intéresse pas, tu ne l'utilises pas. Le but n'est pas de tout remplacer mais d'améliorer un cas d'usage qui est pour le moment non gérable.
Et forcément pour faire ça, oui il faut du bout de code et de config dans l'initrd car le disque dur est chiffré, oui des données doivent être stockées ailleurs par rapport à nos habitudes, etc. Mais il n'y a pas d'autre choix, en fait.