SystemD: le retour de la vengeance - Page 1

Godzil a souhaité poursuivre une discussion dérivée dans un nouveau sujet. La discussion initiale a eu lieu dans le sujet topics/132745-linux/233#post-6969 tandis que la discussion dérivée continue dans le sujet topics/188198-systemd-le-retour-de-la-vengeance où les messages en rapport ont été copiés.

De la même façon que certains parisiens pensent que le monde se limite à Paris, certains pensent que l'informatique se limite aux PCs ^^

Sinon en parlant de systemd, quelqu'un faisait remarquer que ce serait l'endroit idéal pour planquer une backdoor dans Linux : ça a un accès privilégié à tout plein de trucs, le code est assez opaque et ça n'est pas audité comme peut l'être le noyau. Je ne dis pas que c'est le cas, mais ça donne à réfléchir.

Pas besoin, il y a assez de failles pour ca

C'est l'autre possibilité

Godzil (./6938) :
Kevin: de l'embarque?? UEFI?

Godzil (./6940) :
(c'est vraiment tout sauf un bootloader pour l'embarqué, ca ne marche que sur PC..)

Pas vrai. Contrairement au vieux BIOS, UEFI a été conçu pour être portable, ça existe aussi au moins sous aarch64 (ARM 64-bits).

Et j'insiste, systemd-boot a été conçu pour un usage embarqué.

https://wiki.archlinux.org/index.php/systemd-boot
systemd-boot, previously called gummiboot, is a simple UEFI boot manager which executes configured EFI images

ni cette page ni https://en.wikipedia.org/wiki/Gummiboot_(software) ne parlent d'embarqué

google n'est pas bavard sur le sujet non plus
https://www.google.fr/search?q=systemd-boot+embedded

aarch64 n'est pas non plus spécialement fait pour l'embarqué.

donc source||gtfo

edit: yen a qui se font plaiz sur twitter

Ping @systemdsucks pic.twitter.com/2kdEYxzX4d

— Uppgiven liberal (@Qeruiem) July 12, 2017

Zerosquare (./6941) :
Sinon en parlant de systemd, quelqu'un faisait remarquer que ce serait l'endroit idéal pour planquer une backdoor dans Linux : ça a un accès privilégié à tout plein de trucs, le code est assez opaque et ça n'est pas audité comme peut l'être le noyau. Je ne dis pas que c'est le cas, mais ça donne à réfléchir.

Ce n'est pas évident.
1) comme dit Godzil, il y a déjà tout plein de failles partout
2) globalement, systemd « n'invente rien » : les besoins (et donc les élévations de privilèges) existaient avant systemd et étaient remplis par d'autres scripts (cron, at, init, …). Ce n'est pas évident que les différents binaires historiques soient mieux codés.
3) avec init, tu dois auditer le système d'init + tous les scripts shell plus ou moins pourris ET exécutés en root pour tous les services installés. avec systemd, tu ne dois auditer que le code de systemd.
4) systemd permet de limiter assez finement les ressources utilisables par chaque service. À ce niveau, c'est plutôt un gain

Zerosquare (./6937) :
./6923 : j'ai creusé un peu, et bon sang... j'ai beau ne pas être utilisateur de Linux, plus je lis de trucs sur systemd, plus ça me confirme dans la mauvaise opinion que j'ai de ce machin (et du mec qui est derrière). Je ne comprends pas que Linus laisse son OS se faire saboter comme ça, franchement.

Effectivement, on entend beaucoup parler des défauts, mais il y a aussi les gens qui refusent d'apprendre à utiliser les nouvelles commandes.

Bref, sans être fan de systemd (même si honnêtement ça me simplifie bien la vie), la réalité est loin d'être aussi binaire qu'on peut le lire.

flanker (./6948) :
1) comme dit Godzil, il y a déjà tout plein de failles partout

C'est pas une excuse
Et il y a déjà eu des tentatives par le passé d'introduire des backdoors dans Linux, donc c'est que certains doivent trouver que les failles ne suffisent pas.

flanker (./6948) :
Ce n'est pas évident que les différents binaires historiques soient mieux codés.

Certes, mais ils sont beaucoup plus petits et plus simples que systemd. Et leurs mainteneurs ne refusent pas de reconnaître et de corriger leurs bugs.

flanker (./6948) :
3) avec init, tu dois auditer le système d'init + tous les scripts shell plus ou moins pourris ET exécutés en root pour tous les services installés. avec systemd, tu ne dois auditer que le code de systemd.

Oui, mais le code de systemd est massif.

Zerosquare (./6937) :
Effectivement, on entend beaucoup parler des défauts, mais il y a aussi les gens qui refusent d'apprendre à utiliser les nouvelles commandes.

Je parlais des vrais défauts (les bugs, et surtout la philosophie et l'attitude des mainteneurs), pas du fait de changer des habitudes.

Zerosquare (./6949) :

flanker (./6948) :
Ce n'est pas évident que les différents binaires historiques soient mieux codés.

Certes, mais ils sont beaucoup plus petits et plus simples que systemd. Et leurs mainteneurs ne refusent pas de reconnaître et de corriger leurs bugs.

Pour le coup, je ne sais pas. Quels sont tous ces binaires historiques ? Quelle taille font-ils, au total ? Leur code est-il propre ?

flanker (./6948) :
3) avec init, tu dois auditer le système d'init + tous les scripts shell plus ou moins pourris ET exécutés en root pour tous les services installés. avec systemd, tu ne dois auditer que le code de systemd.

Oui, mais le code de systemd est massif.

Tant que ça ? (la partie critique s'entend : l'ensemble est découpé en pas mal de parties qui n'ont pas toutes beaucoup de privilèges)

Zerosquare (./6937) :
Effectivement, on entend beaucoup parler des défauts, mais il y a aussi les gens qui refusent d'apprendre à utiliser les nouvelles commandes.

Je parlais des vrais défauts (les bugs, et surtout la philosophie et l'attitude des mainteneurs), pas du fait de changer des habitudes.

ce n'est pas parfait, c'est certain. Mais de là à dire qu'il faut tout jeter et repartir 30 ans en arrière, il y a un pas que je ne franchirai pas…

L'approche de systemd est à l'origine celle de launchd (macOS) puis upstart (Ubuntu), freebsd bosse sur un truc équivalent de mémoire. Ça commence à faire du monde qui a les mêmes idées, elles ne sont peut-être pas si idiotes que ça ^^

flanker (./6950) :
Mais de là à dire qu'il faut tout jeter et repartir 30 ans en arrière, il y a un pas que je ne franchirai pas…

Ça tombe bien, je n'ai pas dit ça

L'idée de moderniser le système d'init n'est pas mauvaise en soi, et comme tu le fais remarquer, systemd n'est pas le premier à le faire (et les autres tentatives n'ont pas généré autant de remous et de rejet). Le souci est de confier quelque chose d'aussi critique a des gens comme Lennart Poettering, dont la qualité du code et surtout le comportement posent problème. Un projet peut être excellent sur le papier, mais s'il est mal implémenté et mal géré, c'est tout-à-fait légitime de lui préférer quelque chose d''archaïque" mais de mieux maîtrisé.

je suis d'accord.

Si systèmes s
'Arrêtait as init tu pourrais comparer à upstart ou launchd.

Il y a un truc que je trouve assez étrange, quand-même. On sait que ce gars est un gros lourd. On sait que ces bugs sont critiques. On est dans du logiciel libre sous licence libre. Pourquoi il n'y a pas une équipe pour faire un fork (surtout du côté des grosses distribs), corriger les bugs, et renommer le tout SystemB ? Parce que là, je ne vois aucun intérêt à être dans un système libre si c'est pour être coincé dès qu'un gars refuse de changer quelque chose...

Je dirais que c'est parce que il y a RedHat qui est un poids lourd derrière. Pour le remplacer il faudrait qu'une entreprise ait envie d'investir autant que Redhat là dedans.

Mais, du coup, pourquoi RH laisse faire ?

Parceque c'est une societe philantropico-communiste qui cherche le bien de tous

Parce que c'est justement dans leur intérêt d'avoir réussi à introduire un module fondamental et sous leur contrôle dans la plupart des distributions Linux ?

Ce n'est pas la première fois que ce cas se produit. Il s'était déjà passé la même chose avec Ulrich Drepper qui gérait glibc, qui avait le même genre de comportement que Poettering, et qui travaillait aussi pour RedHat. À tel point que Debian avait fini par en avoir marre et avait switché vers eglibc.

Zerosquare (./6958) :
Parce que c'est justement dans leur intérêt d'avoir réussi à introduire un module fondamental et sous leur contrôle dans la plupart des distributions Linux ?

Oui, ça je veux bien le comprendre, mais je parle du fait de laisser à une seule personne, connue pour ses décisions, la gestion d'un truc critique et qui, justement, est réutilisé par tout le monde.
Ils prennent le risque d'un fork et qu'on laisse tomber leur solution...

Non parce qu'ils contrôlent désormais des point clefs du système comme udev. (Qui n'a rien à voir avec initnou la gestion de daemon bien entendu, tout comme logind, leur resolver DNS etc...

Le problème c'est que si tu veux un gnome ou même un KDE tu n'a pas le choix ton bousin dépends que de trop de systemd.

Nil > Je pense que c'est un risque qu'ils ont choisi de prendre. Microsoft a utilisé la même stratégie par le passé : arriver à se positionner comme le standard que tout le monde utilise ou doit égaler, et en profiter pour garder une longueur d'avance sur ses concurrents, quitte à prendre des décisions qui font grincer des dents. Et globalement ça a marché, du moins pendant un certain temps, parce que passer à une solution alternative avait un coût non négligeable.

C'est exactement le problème qui se pose. Former et assainir la chose n'est pas mission impossible mais sors complètement du cadre traditionnel d'un projet OSS

Zerosquare (./6958) :
Ce n'est pas la première fois que ce cas se produit. Il s'était déjà passé la même chose avec Ulrich Drepper qui gérait glibc, qui avait le même genre de comportement que Poettering, et qui travaillait aussi pour RedHat. À tel point que Debian avait fini par en avoir marre et avait switché vers eglibc.

Je trouve qu'Ulrich Drepper faisait un très bon travail de mainteneur de glibc et que c'est vraiment dommage qu'il soit parti (vers Goldman Sachs ). Avec lui, on n'aurait jamais eu cette merde de Flatpak, ces idées existaient déjà à l'époque, et il a expliqué très clairement et fermement pourquoi c'est de la merde. (À mort les applications blob!)

Ce que veut dire Nil si je comprends bien c'est pourquoi Red Hat laisse Poettring tout seul sur le projet, sachant qu'il fait grincer des dents. Et je me pose la même question à vrai dire…

Parce que RedHat en a RAF tout simplement? ca leur rapport encroe plus de controle sur le monde de Systemd-kernel je suis un peu en avance, mais c'est probablement le prochain point de controle

Brunni > ben j'ai répondu plus haut : pour l'instant ils gagnent plus qu'ils ne perdent, donc ils laissent faire.

Merci Brunni, oui, c'est exactement ça. Red Hat a beau être une boite qui fait du LL, ça reste une boite privée (et j'imagine que Poettring est rémunéré directement par RH) qui sait gérer des équipes et des projets. Qu'un truc aussi énorme ne repose sur les épaules que d'une seule personne, ça me paraît dingue...

Il n'est pas le seul à bosser sur systemd, il en est "seulement" le créateur, le mainteneur principal et la figure de proue du projet. Et son côté "rentre-dedans", aussi agaçant qu'il soit, a peut-être aidé à pousser son projet, justement.

Nil (./6967) :
et j'imagine que Poettring est rémunéré directement par RH

Bah oui, évidemment. Il est employé par Red Hat, et l'esclavage a été aboli. Donc forcément ils le paient.