As t'on vraiment besoin de mettre du DBUS partout ? Je me suis battu avant Noel avec policy-kit. je voulais supprimer le bouton shutdown et mise en veille du menu de de-connexion XFCE sous debian. J'ai du aller bidouiller plus ou moins à l'aveugle un fichier XML dans /usr/share... Avant, on avait un truc simple basé sur des groupes dans sudo pour faire la même chose.
Les droits unix ne sont pas assez fins, c'est un fait. Peuve en est qu'on a du ajouté pleins d'xattrs, les ACL et capabilities. C'est bien facile de dire "c'était mieux avant", alors que policykit permet plus que sudo.
Sudo, ça donne juste des droits superuser globalement à l'application, alors que policyKit est plus fin : ça permet des élévations de privilèges temporaire par thread, et ça exploite bien les mécanismes de sécurités POSIX sous-jacent. C'est juste une API unifiée pour les applications graphiques.
Après, le choix du XML est une autre histoire, mais bon ça fait longtemps qu'on utilise cette merde pour de la conf utilisateur, eg HAL.
Pour ce qui est des groupes, dire qu'ils ne servent plus à rien est complétement éxagéré. Ils servent à donner des permissions à grande granularité sur les fichiers. Et c'est très utilise dans un environnement multi-utilisateur, mais ça serait idiot de les sur exploiter : vaut il mieux lancer une appli en root, ou lancer une appli en user qui va passer en root durant le laps de temps ou elle en a besoin ?
Pour ce qui est des variables d'environnement, je pense que c'est juste plus adapté. Ça se justifie quand le shell est un shell en ligne de commande au sens classique, mais de nos jour, un utilisateur lambda ne devrait plus en passer par là. Quand on regarde un processus de login sous GNOME, on passe par init → gdm → shell graphique (gnome-shell). Toutes les applications sont lancées par ce shell ou par gnome-session. La vision de variable d'environnement n'a plus aucun sens, les devs gnome les ont remplacées par GSettings. Après on peut débattre du fait que c'est pas human readable, etc mais c'est un autre problème.
Quand à DBus, oui, on a besoin d'un IPC avec un mecanisme de remote procedure call dans un bureau moderne. Que ce soit DBus ou pas. Le fait est que Red Hat et GNOME ont imposé DBus et que maintenant il est là, et pas aussi mauvais qu'on se complait à le dire. DBus, c'est un peu au bureau ce qu'ont été les sockets à Unix. (bon j'éxagère, en plus il y avait Dcop et cobra avant, mais enfin). Les applications ont besoin d'un moyen simple de se notifier et de se transferer des infos.
En outre, toutes ces technologies ne remplacent pas les vieux mécanismes unix éprouvés et tant chéris, elles viennent s'ajouter au dessus pour faciliter le developement. DBus utilise les sockets, policikit utilise DBus et PAM. Parfois, ce n'est pas parce que ça ressemble à Windows que c'est mal.
[^] # Re: C'est grâce à GNOME 3 et KDE 4.
Posté par Enjolras . En réponse à la dépêche Le succès sans précédent de Linux sur le bureau. Évalué à 4. Dernière modification le 07 janvier 2012 à 20:29.
Les droits unix ne sont pas assez fins, c'est un fait. Peuve en est qu'on a du ajouté pleins d'xattrs, les ACL et capabilities. C'est bien facile de dire "c'était mieux avant", alors que policykit permet plus que sudo.
Sudo, ça donne juste des droits superuser globalement à l'application, alors que policyKit est plus fin : ça permet des élévations de privilèges temporaire par thread, et ça exploite bien les mécanismes de sécurités POSIX sous-jacent. C'est juste une API unifiée pour les applications graphiques.
Après, le choix du XML est une autre histoire, mais bon ça fait longtemps qu'on utilise cette merde pour de la conf utilisateur, eg HAL.
Pour ce qui est des groupes, dire qu'ils ne servent plus à rien est complétement éxagéré. Ils servent à donner des permissions à grande granularité sur les fichiers. Et c'est très utilise dans un environnement multi-utilisateur, mais ça serait idiot de les sur exploiter : vaut il mieux lancer une appli en root, ou lancer une appli en user qui va passer en root durant le laps de temps ou elle en a besoin ?
Pour ce qui est des variables d'environnement, je pense que c'est juste plus adapté. Ça se justifie quand le shell est un shell en ligne de commande au sens classique, mais de nos jour, un utilisateur lambda ne devrait plus en passer par là. Quand on regarde un processus de login sous GNOME, on passe par init → gdm → shell graphique (gnome-shell). Toutes les applications sont lancées par ce shell ou par gnome-session. La vision de variable d'environnement n'a plus aucun sens, les devs gnome les ont remplacées par GSettings. Après on peut débattre du fait que c'est pas human readable, etc mais c'est un autre problème.
Quand à DBus, oui, on a besoin d'un IPC avec un mecanisme de remote procedure call dans un bureau moderne. Que ce soit DBus ou pas. Le fait est que Red Hat et GNOME ont imposé DBus et que maintenant il est là, et pas aussi mauvais qu'on se complait à le dire. DBus, c'est un peu au bureau ce qu'ont été les sockets à Unix. (bon j'éxagère, en plus il y avait Dcop et cobra avant, mais enfin). Les applications ont besoin d'un moyen simple de se notifier et de se transferer des infos.
En outre, toutes ces technologies ne remplacent pas les vieux mécanismes unix éprouvés et tant chéris, elles viennent s'ajouter au dessus pour faciliter le developement. DBus utilise les sockets, policikit utilise DBus et PAM. Parfois, ce n'est pas parce que ça ressemble à Windows que c'est mal.