De plus, run0 évite les complexités de la configuration traditionnelle en utilisant polkit pour l'autorisation,
Le mec qui écrit ça n'est jamais allé voir ce qu'est Polkit. Honnêtement, ce n'est peut-être pas pire que sudo, mais c'est loin d'être mieux …
en rationalisant les interactions avec l'utilisateur et en sécurisant davantage le processus d'exécution.
Bullshit
L'outil ajoute également une touche de convivialité : lorsqu'il fonctionne avec des privilèges élevés, il modifie l'arrière-plan du terminal en lui donnant une teinte rougeâtre, ce qui sert de repère visuel pour indiquer le statut élevé de l'utilisateur - un rappel simple mais efficace pour gérer les privilèges de manière responsable.
OOOOh !!! C'est vrai que c'est LE truc qu'il fallait pour sécuriser son système. Mettre du rouge …
Je ne m'attarde pas sur le reste, mais quand je lis les arguments de Pottering, je retrouve les mêmes que ceux qui se lancent dans une réécriture de code Cobol en Java … Ces mecs qui se croient meilleurs que les anciens, qui remplacent du code, certes pas parfait par un truc qui paraît plus propre en théorie, mais qui ne traite qu'une partie de la problématique auquel répond le code "crade" selon leur point de vue.
Je pense personnellement que le plus gros problème de sudo est le fait qu'il s'agisse d'un binaire SUID
(Citation de l'article lié)
Bon, ok, mais dans ce cas, il faudrait "juste" attaquer le problème à la racine, et s'occuper de PAM, par exemple en portant BSDauth qui n'est aujourd'hui utilisé que par OpenBSD? Qui dit "porter" dit "récupérer l'historique des bugfix" au passage, plutôt que de NiH encore un truc qui sera affecté par des failles de sécurités… parce que l'historique du PID1 systemd est pas super reluisant de ce point de vue, il me semble. Je ne connais pas celui de PAM, mais ce que je sais, c'est qu'une tentative d'installer openldap sur ma machine pour l'expérimentation rendait mon shell inutilisable, dmesg indiquant des segfaults…
Je précise que je n'ai jamais utilisé openBSD (et donc bsdauth), mais à vue de nez ça passe aussi par une archi client-serveur, probablement en exploitant la capacité d'AF_UNIX de pouvoir transférer des descripteurs de fichier.
Plan9 à priori a un équivalent, encore plus poussé mais j'ignore entièrement comment ça marche: majordomo je crois?
J'ai essayé de trouver plus d'infos techniques sur le sujet, sans succès :/ (parce que l'idée me plaît beaucoup, à moi. Enfin, pas trop étudié le défunt p9, parce que de toute façon ils doivent avoir recours a des spécificités du kernel ou des patchs de libc.)
OOOOh !!! C'est vrai que c'est LE truc qu'il fallait pour sécuriser son système. Mettre du rouge …
Ca doit être un équivalent des terminaux dont le thème graphique change selon qu'ils soient sous sudo ou non (je crois me souvenir avoir vu ça dans gnome? Il y a longtemps…).
Perso, au boulot, je modifie simplement mon prompt pour que 1) mon username apparaisse en rouge quand je suis UID=0, et 2) mon hostname change de couleur selon la "zone de criticité": bleu pour ma machine, rouge pour la prod, jaune pour mes VMs, etc.
Bref, changer le fond de la couleur du terminal, je parie qu'on peut déjà le faire avec du bash ou zsh…
Ca doit être un équivalent des terminaux dont le thème graphique change selon qu'ils soient sous sudo ou non (je crois me souvenir avoir vu ça dans gnome? Il y a longtemps…).
le problème de ce genre de systèmes, égal que changer le prompt, c'est que le jour où tu te retrouves sur une machine qui n'est pas configurée comme ça tu risques de ne plus faire attention.
Sur une machine différente, si je n'ai plus ma conf, alors à la fois le username et le hostname seront blancs, de mémoire (ça change selon la distro, certes, mais au moins dans le cas de Debian, je suis certain que la couleur est dégagée pour le compte root "parce que root a pas besoin d'être distrait par la couleur" ou un true de ce style…). Même si pas blancs, la probabilité que le hostname soit de couleur et longueur différentes de mon habitude est plutôt élevée.
Donc, j'aurai bel et bien un moyen de me rappeler de faire attention: ni mon login ni mon hostname n'aurons la couleur habituelle qui me dit que je suis en sécurité.
Bien sûr, balader son .profile et ses copains sur une clé USB n'est pas interdit non plus, c'est pas gros et c'est pratique, ça évite de devoir se re-taper tous les alias pour la couleur, par exemple.
Perso je trouve intéressant de questionner les piles de trucs qu'on considère comme normaux sous Unix/Linux, et qu'on conserve comme un héritage précieux. Parfois c'est juste un hack qui contourne une limitation transformé en relique sacrée. Il y a quelques trucs bien qui ressortent du coup de pied dans la fourmilière que représente systemd1.
Donc, changer sudo par autre chose. Pourquoi ? Avoir une granularité plus grande dans les fonctions exécutables en root, et contourner la flemme intersidérale qui fait qu'on termine trop souvent avec un (ALL : ALL) NOPASSWD: ALL dans le sudoers.
Toutefois, ici, le remplacement est d'une complexité bien plus grande que sudo ! La configuration fine se fait par des snippets de configuration Polkit, qui ne sont autre que des fichiers XML qui font référence à des actions encodées dans d'autres fichiers XML, qui correspondent à des interfaces type org.freedesktop.machine1.host-login. Écrire un fichier polkit est un vrai sujet en soi.
Bref, je trouve la question de la gestion des droits admin légitime, mais la solution proposée un peu moyenne car finalement plus complexe. Peut-être que pour un usage de bureau c'est un mal nécessaire.
Au final, peut-être que l'intérêt de tout ça est d'arriver à standardiser la gestion des droits au travers des interfaces freedesktop.
Ma conclusion pour mon usage est que je vais suivre run0 de loin, et si ça donne un truc intéressant, je raccrocherai les wagons.
les logs binaires, qui permettent de chercher par date sans avoir le gros doute sur la timezone ou du format de date, sont un bon exemple de truc bien (c'est mon avis en tout cas :)). ↩
Perso je trouve intéressant de questionner les piles de trucs qu'on considère comme normaux sous Unix/Linux, et qu'on conserve comme un héritage précieux. Parfois c'est juste un hack qui contourne une limitation transformé en relique sacrée. Il y a quelques trucs bien qui ressortent du coup de pied dans la fourmilière que représente systemd
Je suis entièrement d'accord. Pas forcément changer pour changer, mais même si au final on garde la solution initial, on sait mieux pourquoi. Une bonne solution ne devrait pas souffrir de comparaison et ne devrait pas entrainer d'énervement. Bien sûr il y a une part de goût et de diversité des besoins, mais c'est alors bien pour les nouveaux besoins qu'autre chose existe. Si je devais donner une comparaison, certains de ceux qui expliquent que le NoSQL c'est du vent que c'est impropre etc oublie à quel point les SGBDR actuels s'inspirent de choix fait dans les NoSQL (j'ai une pensée toute particulière pour ce podcast où un développeur commence en expliquant comment le NoSQL n'était qu'une mode pour finir en expliquant que si tu veut de la performance tu met tout dans une même table et tu utilise le moteur de stockage column store…).
Toutefois, ici, le remplacement est d'une complexité bien plus grande que sudo ! La configuration fine se fait par des snippets de configuration Polkit, qui ne sont autre que des fichiers XML qui font référence à des actions encodées dans d'autres fichiers XML, qui correspondent à des interfaces type org.freedesktop.machine1.host-login. Écrire un fichier polkit est un vrai sujet en soi.
Il s'agit là de l'API technique actuelle. Il n'y a pas de raison de ne pas faire générer ces XML autrement voir si une solution devient fondamentalement meilleure de la rendre native. À mon avis c'est le fait de ne pas s'en servir qui fait que ça n'est pas amélioré. Je suis pour la pratique qui consiste à dire que si quelque chose est compliqué, il faut le faire plus souvent. Plus fréquemment on fait les choses, plus on va se débrouiller pour l'améliorer.
Il s'agit là de l'API technique actuelle. Il n'y a pas de raison de ne pas faire générer ces XML autrement voir si une solution devient fondamentalement meilleure de la rendre native. À mon avis c'est le fait de ne pas s'en servir qui fait que ça n'est pas amélioré. Je suis pour la pratique qui consiste à dire que si quelque chose est compliqué, il faut le faire plus souvent. Plus fréquemment on fait les choses, plus on va se débrouiller pour l'améliorer.
Je suis pas forcément convaincu de cette approche. On peut justifier à peu près tout, et j'ai déjà vu ça dans des projets de dev. Un dev "influent" va pousser une vague solution à un vague problème qu'il rencontre, et fait face à de la résistance. du coup, les managers utilisent cet argument: "si vous râlez, c'est que vous l'utilisez pas, on va forcer l'usage, et la simplicité viendra". Et ensuite, bah certains devs poussent des rustines, contournent le problème, et le dev influent est content, il dit que sa solution est la meilleure!
C'est tjs un peu pareil : "olalala, c'est trop complexe, je vais faire ça plus simple. step1: un cas unique qui couvre mes besoins. step2: on augmente et on couvre 95% des besoins. step3: on ajoute pleins de cas particuliers. step4: c'est devenu trètrètrècompliqué didon!" rinse and repeat. Il y a un step3 aussi: "vos cas particuliers ne seront pas traités, modifiez tout pour coller à mon cas d'usage que j'ai défini. Pliez vous y ou dégagez, c'est du LL, libre à toi de tout redev dans ton coin".
Le problème que tu décris c'est plus un problème de gestion des décisions que d'arguments.
C'est pas un argument. C'est une pratique. C'est à l'équipe de savoir où elle veut aller et c'est en faisant que l'on repère les difficultés et qu'on les corrige. D'expérience la partie code, s'il y en a une, est anecdotique car c'est une question de pratique.
Là par exemple faire un outil pour générer des XML à partir d'autres choses, c'est pas un renversement de table. Et l'intérêt c'est justement de réutiliser polkit qui est là, qui marche bien,… Le reproche de tout casser à une solution qui consiste à réutiliser l'existant ne me semble pas pertinent
# Je me marre quand je lis ses arguments (à moins qu'ils aient été mal retranscrits )
Posté par totof2000 . Évalué à 10.
Le mec qui écrit ça n'est jamais allé voir ce qu'est Polkit. Honnêtement, ce n'est peut-être pas pire que sudo, mais c'est loin d'être mieux …
Bullshit
OOOOh !!! C'est vrai que c'est LE truc qu'il fallait pour sécuriser son système. Mettre du rouge …
Je ne m'attarde pas sur le reste, mais quand je lis les arguments de Pottering, je retrouve les mêmes que ceux qui se lancent dans une réécriture de code Cobol en Java … Ces mecs qui se croient meilleurs que les anciens, qui remplacent du code, certes pas parfait par un truc qui paraît plus propre en théorie, mais qui ne traite qu'une partie de la problématique auquel répond le code "crade" selon leur point de vue.
[^] # Re: Je me marre quand je lis ses arguments (à moins qu'ils aient été mal retranscrits )
Posté par freem . Évalué à 9.
(Citation de l'article lié)
Bon, ok, mais dans ce cas, il faudrait "juste" attaquer le problème à la racine, et s'occuper de PAM, par exemple en portant BSDauth qui n'est aujourd'hui utilisé que par OpenBSD? Qui dit "porter" dit "récupérer l'historique des bugfix" au passage, plutôt que de NiH encore un truc qui sera affecté par des failles de sécurités… parce que l'historique du PID1 systemd est pas super reluisant de ce point de vue, il me semble. Je ne connais pas celui de PAM, mais ce que je sais, c'est qu'une tentative d'installer openldap sur ma machine pour l'expérimentation rendait mon shell inutilisable, dmesg indiquant des segfaults…
Je précise que je n'ai jamais utilisé openBSD (et donc bsdauth), mais à vue de nez ça passe aussi par une archi client-serveur, probablement en exploitant la capacité d'AF_UNIX de pouvoir transférer des descripteurs de fichier.
Plan9 à priori a un équivalent, encore plus poussé mais j'ignore entièrement comment ça marche: majordomo je crois?
J'ai essayé de trouver plus d'infos techniques sur le sujet, sans succès :/ (parce que l'idée me plaît beaucoup, à moi. Enfin, pas trop étudié le défunt p9, parce que de toute façon ils doivent avoir recours a des spécificités du kernel ou des patchs de libc.)
Ca doit être un équivalent des terminaux dont le thème graphique change selon qu'ils soient sous sudo ou non (je crois me souvenir avoir vu ça dans gnome? Il y a longtemps…).
Perso, au boulot, je modifie simplement mon prompt pour que 1) mon username apparaisse en rouge quand je suis UID=0, et 2) mon hostname change de couleur selon la "zone de criticité": bleu pour ma machine, rouge pour la prod, jaune pour mes VMs, etc.
Bref, changer le fond de la couleur du terminal, je parie qu'on peut déjà le faire avec du bash ou zsh…
[^] # Re: Je me marre quand je lis ses arguments (à moins qu'ils aient été mal retranscrits )
Posté par Psychofox (Mastodon) . Évalué à 4.
le problème de ce genre de systèmes, égal que changer le prompt, c'est que le jour où tu te retrouves sur une machine qui n'est pas configurée comme ça tu risques de ne plus faire attention.
[^] # Re: Je me marre quand je lis ses arguments (à moins qu'ils aient été mal retranscrits )
Posté par ff9097 . Évalué à 6.
Le jour où tu te retrouves sur une machine avec un terminal non-compatible c'est la même chose
[^] # Re: Je me marre quand je lis ses arguments (à moins qu'ils aient été mal retranscrits )
Posté par freem . Évalué à 3.
Sur une machine différente, si je n'ai plus ma conf, alors à la fois le username et le hostname seront blancs, de mémoire (ça change selon la distro, certes, mais au moins dans le cas de Debian, je suis certain que la couleur est dégagée pour le compte root "parce que root a pas besoin d'être distrait par la couleur" ou un true de ce style…). Même si pas blancs, la probabilité que le hostname soit de couleur et longueur différentes de mon habitude est plutôt élevée.
Donc, j'aurai bel et bien un moyen de me rappeler de faire attention: ni mon login ni mon hostname n'aurons la couleur habituelle qui me dit que je suis en sécurité.
Bien sûr, balader son
.profileet ses copains sur une clé USB n'est pas interdit non plus, c'est pas gros et c'est pratique, ça évite de devoir se re-taper tous les alias pour la couleur, par exemple.# Still hungry
Posté par Xanatos . Évalué à 10.
Bon vendredi !
[^] # Re: Still hungry
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1.
C'est aussi mon avis. :D
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
# Conf Polkit pour remplacer sudo
Posté par cg . Évalué à 10.
(note: le sujet "sudo pas bien, run0 bien" est aussi abordé ici : sudo" is very very useful […] sudo has serious problems though).
Perso je trouve intéressant de questionner les piles de trucs qu'on considère comme normaux sous Unix/Linux, et qu'on conserve comme un héritage précieux. Parfois c'est juste un hack qui contourne une limitation transformé en relique sacrée. Il y a quelques trucs bien qui ressortent du coup de pied dans la fourmilière que représente systemd1.
Donc, changer sudo par autre chose. Pourquoi ? Avoir une granularité plus grande dans les fonctions exécutables en root, et contourner la flemme intersidérale qui fait qu'on termine trop souvent avec un
(ALL : ALL) NOPASSWD: ALLdans le sudoers.Toutefois, ici, le remplacement est d'une complexité bien plus grande que sudo ! La configuration fine se fait par des snippets de configuration Polkit, qui ne sont autre que des fichiers XML qui font référence à des actions encodées dans d'autres fichiers XML, qui correspondent à des interfaces type
org.freedesktop.machine1.host-login. Écrire un fichier polkit est un vrai sujet en soi.Bref, je trouve la question de la gestion des droits admin légitime, mais la solution proposée un peu moyenne car finalement plus complexe. Peut-être que pour un usage de bureau c'est un mal nécessaire.
À comparer à d'autres solutions comme les capabilities (et aussi Root As Role)
Au final, peut-être que l'intérêt de tout ça est d'arriver à standardiser la gestion des droits au travers des interfaces freedesktop.
Ma conclusion pour mon usage est que je vais suivre run0 de loin, et si ça donne un truc intéressant, je raccrocherai les wagons.
les logs binaires, qui permettent de chercher par date sans avoir le gros doute sur la timezone ou du format de date, sont un bon exemple de truc bien (c'est mon avis en tout cas :)). ↩
[^] # Re: Conf Polkit pour remplacer sudo
Posté par cg . Évalué à 9.
Pardon j'ai écrit une bêtise : les actions de Polkit sont bien en XML, mais les règles sont en JavaScript.
[^] # Re: Conf Polkit pour remplacer sudo
Posté par barmic 🦦 . Évalué à 6.
Je suis entièrement d'accord. Pas forcément changer pour changer, mais même si au final on garde la solution initial, on sait mieux pourquoi. Une bonne solution ne devrait pas souffrir de comparaison et ne devrait pas entrainer d'énervement. Bien sûr il y a une part de goût et de diversité des besoins, mais c'est alors bien pour les nouveaux besoins qu'autre chose existe. Si je devais donner une comparaison, certains de ceux qui expliquent que le NoSQL c'est du vent que c'est impropre etc oublie à quel point les SGBDR actuels s'inspirent de choix fait dans les NoSQL (j'ai une pensée toute particulière pour ce podcast où un développeur commence en expliquant comment le NoSQL n'était qu'une mode pour finir en expliquant que si tu veut de la performance tu met tout dans une même table et tu utilise le moteur de stockage column store…).
Il s'agit là de l'API technique actuelle. Il n'y a pas de raison de ne pas faire générer ces XML autrement voir si une solution devient fondamentalement meilleure de la rendre native. À mon avis c'est le fait de ne pas s'en servir qui fait que ça n'est pas amélioré. Je suis pour la pratique qui consiste à dire que si quelque chose est compliqué, il faut le faire plus souvent. Plus fréquemment on fait les choses, plus on va se débrouiller pour l'améliorer.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Conf Polkit pour remplacer sudo
Posté par octane . Évalué à 9.
Je suis pas forcément convaincu de cette approche. On peut justifier à peu près tout, et j'ai déjà vu ça dans des projets de dev. Un dev "influent" va pousser une vague solution à un vague problème qu'il rencontre, et fait face à de la résistance. du coup, les managers utilisent cet argument: "si vous râlez, c'est que vous l'utilisez pas, on va forcer l'usage, et la simplicité viendra". Et ensuite, bah certains devs poussent des rustines, contournent le problème, et le dev influent est content, il dit que sa solution est la meilleure!
C'est tjs un peu pareil : "olalala, c'est trop complexe, je vais faire ça plus simple. step1: un cas unique qui couvre mes besoins. step2: on augmente et on couvre 95% des besoins. step3: on ajoute pleins de cas particuliers. step4: c'est devenu trètrètrècompliqué didon!" rinse and repeat. Il y a un step3 aussi: "vos cas particuliers ne seront pas traités, modifiez tout pour coller à mon cas d'usage que j'ai défini. Pliez vous y ou dégagez, c'est du LL, libre à toi de tout redev dans ton coin".
[^] # Re: Conf Polkit pour remplacer sudo
Posté par barmic 🦦 . Évalué à 5.
Le problème que tu décris c'est plus un problème de gestion des décisions que d'arguments.
C'est pas un argument. C'est une pratique. C'est à l'équipe de savoir où elle veut aller et c'est en faisant que l'on repère les difficultés et qu'on les corrige. D'expérience la partie code, s'il y en a une, est anecdotique car c'est une question de pratique.
Là par exemple faire un outil pour générer des XML à partir d'autres choses, c'est pas un renversement de table. Et l'intérêt c'est justement de réutiliser polkit qui est là, qui marche bien,… Le reproche de tout casser à une solution qui consiste à réutiliser l'existant ne me semble pas pertinent
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.