Il y en a un paquet qui tombent régulièrement. La nécessité d'être root pour la majorité des opérations + la centralisation des méthodes de sécurité + la compelxité polkit/consolekit + ... font qu'il risque de falloir un bon moment avant qu'il n'y ait pas deux ou 3 CVE par jour. (Rien que sur le bugzilla RH il y a eu plus de 5000 CVE systemd/udev don certains CANT et WONTFIX qui ne me donnent pas confiance.)
Hum, systemd est incapable de lancer un processus avec un autre utilisateur que root ? Ou alors je ne comprends pas.
Non le problème c'est qu'un service qui est lancé avec autre chose que le cgroup le plus haut hierarchiquement et des droits root ne peut pas auditer/interragir/démarrer/redémarrer un autre processus. Ca n'est juste pas acceptable. J'ai besoin que Nagios (par exemple) puisse démarrer tout seul comme un grand nombre d'autres services, lesquels services doivent pouvoir interagir avec les services critiques, le tout surtout sans être root. C'est la base de l'admin système : on a des sondes qui tournent en permanence , mais pas beaucoup parceque les ressources sont pas gratuite. Et quand on a un soucis on doit pouvoir lancer d'autres services ou sondes qui vont essayer de diagnostiquer le problème - soitpour le corriger automatiquement (rare) soit au moins pour que l'admin n'ait pas à lancer 200 commandes à la queue leu leu pour se faire un idée de la situation.
Il faut aussi en cas de pépins pouvoir remonter des infos aux utilisateurs/à la production/aux admins services pour qu'il puissent réagir etc.
Tout n'est pas forcément accessible depuis les logs, et je vais pas refiler les droits root aux services qui créé le tableau de bord du client...
Après c'est comme tout quand tu fais tomber un goulot d'étranglement tu en a un autre qui apparaît, mais c'est pas pour ça que ça ne sert à rien de l'avoir supprimé.
Mais il n'y a pas de goulot d'étranglement à ce niveau là. Je ne peux pas faire un diagnostique de mon data-center toute les minutes ce serait ultra consommateur de ressources pour rien - et d'un autre coté dans le cadre d'un cloud elastique je ne peux pas non plus demander au client de patienter une minute à chaque fois qu'il fait une modif ou qu'il passe d'un status iddle à un status plein régime. Donc l'ensemble du problème de consommation électrique ou de densité des data-center repose sur l'anticipation des admins et les optimisations du data-center. Le temps de boot d'une machine - dans la mesure ou il reste très inférieur au temps de mise à jour du status du data center ne rentre pas en compte.
Si je mets 8 minutes à mettre à jour le "load" de mon data center (ce qui sera déjà une performance - ou alors un gaspillage de performance suivant comment c'est fait), je ne vais pas attendre tout ce temps pour me dire "tiens ? On est plein il faudrait peut-être lancer un nouvel hyperviseur/monter des réseau virtuels des fois que la charge augmente". Comparé à ces huit minutes d'anticipation obligatoires (et encore une fois poler un datacenter complet en 8 minutes ca demande un certain doigté) les 4 secondes que va me faire gagner systemd au boot je m'en cogne. Le temps de boot de l'init c'est le 6 ème chiffre après la virgule d'une opération sur trois chiffres significatifs.
[^] # Re: Le vendredi c'est permis.
Posté par Kaane . En réponse à la dépêche Mise aux poings sur systemd. Évalué à 0.
Tu as des CVE à montrer ?
Il y en a un paquet qui tombent régulièrement. La nécessité d'être root pour la majorité des opérations + la centralisation des méthodes de sécurité + la compelxité polkit/consolekit + ... font qu'il risque de falloir un bon moment avant qu'il n'y ait pas deux ou 3 CVE par jour. (Rien que sur le bugzilla RH il y a eu plus de 5000 CVE systemd/udev don certains CANT et WONTFIX qui ne me donnent pas confiance.)
Rien que pour les bugs confirmés ou plus :
https://bugzilla.redhat.com/buglist.cgi?bug_status=ASSIGNED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&component=systemd&component=udev&component=udev-browse&component=udev-extras&limit=0&order=bug_status%2Cpriority%2Cassigned_to%2Cbug_id&query_format=advanced
Hum, systemd est incapable de lancer un processus avec un autre utilisateur que root ?
Ou alors je ne comprends pas.
Non le problème c'est qu'un service qui est lancé avec autre chose que le cgroup le plus haut hierarchiquement et des droits root ne peut pas auditer/interragir/démarrer/redémarrer un autre processus. Ca n'est juste pas acceptable. J'ai besoin que Nagios (par exemple) puisse démarrer tout seul comme un grand nombre d'autres services, lesquels services doivent pouvoir interagir avec les services critiques, le tout surtout sans être root. C'est la base de l'admin système : on a des sondes qui tournent en permanence , mais pas beaucoup parceque les ressources sont pas gratuite. Et quand on a un soucis on doit pouvoir lancer d'autres services ou sondes qui vont essayer de diagnostiquer le problème - soitpour le corriger automatiquement (rare) soit au moins pour que l'admin n'ait pas à lancer 200 commandes à la queue leu leu pour se faire un idée de la situation.
Il faut aussi en cas de pépins pouvoir remonter des infos aux utilisateurs/à la production/aux admins services pour qu'il puissent réagir etc.
Tout n'est pas forcément accessible depuis les logs, et je vais pas refiler les droits root aux services qui créé le tableau de bord du client...
Après c'est comme tout quand tu fais tomber un goulot d'étranglement tu en a un autre qui apparaît, mais c'est pas pour ça que ça ne sert à rien de l'avoir supprimé.
Mais il n'y a pas de goulot d'étranglement à ce niveau là. Je ne peux pas faire un diagnostique de mon data-center toute les minutes ce serait ultra consommateur de ressources pour rien - et d'un autre coté dans le cadre d'un cloud elastique je ne peux pas non plus demander au client de patienter une minute à chaque fois qu'il fait une modif ou qu'il passe d'un status iddle à un status plein régime. Donc l'ensemble du problème de consommation électrique ou de densité des data-center repose sur l'anticipation des admins et les optimisations du data-center. Le temps de boot d'une machine - dans la mesure ou il reste très inférieur au temps de mise à jour du status du data center ne rentre pas en compte.
Si je mets 8 minutes à mettre à jour le "load" de mon data center (ce qui sera déjà une performance - ou alors un gaspillage de performance suivant comment c'est fait), je ne vais pas attendre tout ce temps pour me dire "tiens ? On est plein il faudrait peut-être lancer un nouvel hyperviseur/monter des réseau virtuels des fois que la charge augmente". Comparé à ces huit minutes d'anticipation obligatoires (et encore une fois poler un datacenter complet en 8 minutes ca demande un certain doigté) les 4 secondes que va me faire gagner systemd au boot je m'en cogne. Le temps de boot de l'init c'est le 6 ème chiffre après la virgule d'une opération sur trois chiffres significatifs.