Dans un cas, on parle d'une fonction dans le noyau qui est utilisée par des processus privilégiés et qui parse une bête ligne séparée par des virgules. La fonction mélange certes le parsing, la validation et l'interprétation, mais c'est typique des devs C qui aiment bien coder directement les choses plutôt que de chercher à les abstraire. Mais bon, c'est le langage qui veut que les solutions les plus propres soit les plus lentes et grosses.
Dans l'autre cas, on parle d'un processus utilisateur avec des problématiques de sécurité, vu que ça gère des mots de passes. Certains appels de fonction ne sont pas vérifiés, pas même pour afficher un message d'erreur. La fonction wall_tty_block() exposée au dessus crée un fifo sans même vérifier le message d'erreur, et ne vérifie qu'il à été crée qu'avec un open(), qui peut ouvrir n'importe quoi, sans parler de races. Tout ça pour quoi ? pour faire de l'IPC à la sauce étudiant, comme le montre ce commentaire :
/* We use named pipes to ensure that wall messages suggesting * password entry are not printed over password prompts * already shown. We use the fact here that opening a pipe in * non-blocking mode for write-only will succeed only if * there's some writer behind it. Using pipes has the * advantage that the block will automatically go away if the * process dies. */
Pas non plus de trace de mlock() pour éviter que le mot de passe se retrouve dans le swap. Enfin bref, les pieds nickelés font de la sécurité.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par Batchyx . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 6.
Hein ? quoi ?
Dans un cas, on parle d'une fonction dans le noyau qui est utilisée par des processus privilégiés et qui parse une bête ligne séparée par des virgules. La fonction mélange certes le parsing, la validation et l'interprétation, mais c'est typique des devs C qui aiment bien coder directement les choses plutôt que de chercher à les abstraire. Mais bon, c'est le langage qui veut que les solutions les plus propres soit les plus lentes et grosses.
Dans l'autre cas, on parle d'un processus utilisateur avec des problématiques de sécurité, vu que ça gère des mots de passes. Certains appels de fonction ne sont pas vérifiés, pas même pour afficher un message d'erreur. La fonction
wall_tty_block()exposée au dessus crée un fifo sans même vérifier le message d'erreur, et ne vérifie qu'il à été crée qu'avec un open(), qui peut ouvrir n'importe quoi, sans parler de races. Tout ça pour quoi ? pour faire de l'IPC à la sauce étudiant, comme le montre ce commentaire :Pas non plus de trace de
mlock()pour éviter que le mot de passe se retrouve dans le swap. Enfin bref, les pieds nickelés font de la sécurité.