[ConsoleKit & PolicyKit] Qu'es aquò ?

[gyo]

Bonjour,

Depuis un petit moment j’entend parler à droite à gauche de ces euh… framework que sont ConsoleKit et PolicyKit.

J’ai évidemment lu les différents wiki sur le sujet (merci tuxce), mais dans mon esprit ça reste un peu abscons/confus.

Je sais que ça a un rapport avec hal/dbus mais hal je ne l’utilise (pour l’instant) que pour la partie hotplug de Xorg.

D’après le wiki ce couple (consolekit/policykit) a un rapport avec les droits sur ce que peu faire (ou ne pas faire) l’utilisateur par rapport au matériel (ex : montage disque) et logiciel (ex : régler l’horloge).

Dans un environnement (pseudo)mono-utilisateur (un seul utilisateur en plus de root), est-ce que celà a un réel intérêt ? Étant donné que j’utilise sudo pour faire des manipulations qui requiert des droits de super-utilisateur.

Je précise que j’utilise awesome comme environnement, que je suis un adepte des environnements légers et que je suis un gros dino

Si quelqu’un pouvait éclairer ma lanterne pour un béotien comme moi en matière de Hal et Cie, ce serait sympa

P-S : *Kit c’est KISS ? (à première vue j’ai pas l’impression )

[EDIT] des éléments de réponse ici : http://artisan.karma-lab.net/node/1523
(je regarderai ça)

[mimas]

C'est pour réduire la quantité du code fonctionnant avec privilèges.

Policikit, à l'opposé de sudo va permettre à des programmes non privilégiés de communiquer avec des applications privilégiées et d'agir sur le système. Par exemple, l'appli truc exécutée par Bidule à le droit de dire à hal de monter la clef usb, tandis la même appli exécutée par Chose n'aura pas le droit.

Cela permet de modulariser et, au lieu de tout mettre l'application sous certains privilèges, on va la faire communiquer (ou non suivant la configuration) avec des modules qui en ont.

C'est vachement cool dans la théorie. Dans la pratique ça à l'air de merder chez archlinux.

PS: Il y a un accent sur le o : qu'es aquò.

[tuxce]

plusieurs choses ... par quoi commencer ... ah oui:

C'est vachement cool dans la théorie. Dans la pratique ça à l'air de merder chez archlinux.

C'est effectivement une avancée à mon avis et je ne pense pas être le seul
Par contre, ça fonctionne parfaitement sous archlinux, là où ça coince, c'est que sur archlinux contrairement à d'autres distributions, l'utilisateur choisit la plupart du temps de démarrer sa session comme il l'entend, xinitrc ou autre et s'il ne met pas à jour de son propre chef pour y rajouter le démarrage de consolekit, aucun soft ne le fera pour lui

De plus, en upstream, certaines autorisations ne sont pas encore (ou ne l'étaient pas lors de la construction du paquet) incluses notamment celles des partitions ntfs, archlinux ayant pour politique de patcher le moins possible, surtout si plus est, un contournement est facile à mettre en oeuvre par l'utilisateur, des fois ça coince par manque de doc... (mais normalement, y a la totale )

En fait je ne sais pas si c'est hal qui le fait réellement.

Hal est là, mise en avant parce que c'est le sommet de l'iceberg, on se rend compte que les *kit existe quand on arrive pas à monter une partition
Mais en réalité, hal est ici au même niveau que n'importe quel soft, il crée des "actions" (cf. wiki policykit) qui sont soumis à des droits, et vérifie ces droits lorsque la méthode liée à l'action est appelée.

Dans un environnement (pseudo)mono-utilisateur (un seul utilisateur en plus de root), est-ce que celà a un réel intérêt ? Étant donné que j’utilise sudo pour faire des manipulations qui requiert des droits de super-utilisateur.

Tout dépend du degré de "desktop attitude" (gyo rajoute moi le "TM" dont les bépoistes ont le secret à la place des () ) que tu veux, si pour toi, (des exempes au pif) changer de réseaux wifi/d'heure/monter une partition externe/..., doit demander un mdp root et que toute une application soit démarré en root ne te gène pas, pas besoin de policykit.
encore plus si tu n'utilises aucune applications demandant policykit...

De plus en plus d'applications commenceront à l'utiliser, mais là avec ce que tu utilises (je sais pas ce que tu utilises pour les partitions), apparemment t'en a pas besoin.

En ce qui concerne ConsoleKit, c'est un peu différent, c'est directement lié à une utilisation multi-utilisateur et/ou multi-site, on peut en théorie s'en passer pour un mono-utilisateur, mono-poste, mais il faut reconfigurer les permissions.

P-S : *Kit c’est KISS ? (à première vue j’ai pas l’impression )

Avant, tout le monde s'occupait de tout, DBUS faisait IPC et gestion de droits, hal faisait matériel et gestion de droits, et les autres softs se lancait ou bien en root ou géraient tout seuls dans leur coins les droits.

Maintenant (en tout cas, c'est le but), dbus c'est un IPC, hal (bientot devicekit ), c'est le matos et les droits peuvent être définis de manière homogènes dans policykit et consolekit s'occupe de détecter la nature de la session, plus KISS que ça, tu meurs, non ?

Voilà, j'espère avoir éclairci

[gyo]

Policikit, à l'opposé de sudo va permettre à des programmes non privilégiés de communiquer avec des applications privilégiées et d'agir sur le système. Par exemple, l'appli truc exécutée par Bidule à le droit de dire à hal de monter la clef usb, tandis la même appli exécutée par Chose n'aura pas le droit.

Finalement comme sudo sans la couche hal/dbus quoi

Cela permet de modulariser et, au lieu de tout mettre l'application sous certains privilèges, on va la faire communiquer (ou non suivant la configuration) avec des modules qui en ont.

Dis, dessine-moi un mouton… (lapincompris)

PS: Il y a un accent sur le o : qu'es aquò.

À priori, oui (’tin je croyais que c’était une expression latine au départ, mais non en fait, c’est de l’occitan )

C'est vachement cool dans la théorie. Dans la pratique ça à l'air de merder chez archlinux.

C'est effectivement une avancée à mon avis et je ne pense pas être le seul
Par contre, ça fonctionne parfaitement sous archlinux, là où ça coince, c'est que sur archlinux contrairement à d'autres distributions, l'utilisateur choisit la plupart du temps de démarrer sa session comme il l'entend, xinitrc ou autre et s'il ne met pas à jour de son propre chef pour y rajouter le démarrage de consolekit, aucun soft ne le fera pour lui

De plus, en upstream, certaines autorisations ne sont pas encore (ou ne l'étaient pas lors de la construction du paquet) incluses notamment celles des partitions ntfs, archlinux ayant pour politique de patcher le moins possible, surtout si plus est, un contournement est facile à mettre en oeuvre par l'utilisateur, des fois ça coince par manque de doc... (mais normalement, y a la totale )

sans vouloir fuder, est-ce que *kit aurait à voir avec certaines personnes qui ont actuellement des problème de mappage clavier avec certaines applications ?

Hal est là, mise en avant parce que c'est le sommet de l'iceberg, on se rend compte que les *kit existe quand on arrive pas à monter une partition
Mais en réalité, hal est ici au même niveau que n'importe quel soft, il crée des "actions" (cf. wiki policykit) qui sont soumis à des droits, et vérifie ces droits lorsque la méthode liée à l'action est appelée.

policykit le « sudo » du hal ? (en faisant un raccourci)

Tout dépend du degré de "desktop attitude"™ (gyo rajoute moi le "TM" dont les bépoistes ont le secret à la place des () ) que tu veux, si pour toi, (des exempes au pif) changer de réseaux wifi/d'heure/monter une partition externe/..., doit demander un mdp root et que toute une application soit démarré en root ne te gène pas, pas besoin de policykit.
encore plus si tu n'utilises aucune applications demandant policykit...

TM --> ™ (cadeau, celà dit on peut le faire en fr/oss )

Mon gestionnaire wifi du moment (RutilT) me demande un mot de passe si je crée un autre profil (je ne le fais pas tous les jours, donc bof)
Pour l’heure c’est ntpd (donc bof)
Montage de partition externe : pmount, je lorgne sur ivman cependant

P-S : *Kit c’est KISS ? (à première vue j’ai pas l’impression )

Avant, tout le monde s'occupait de tout, DBUS faisait IPC et gestion de droits, hal faisait matériel et gestion de droits, et les autres softs se lancait ou bien en root ou géraient tout seuls dans leur coins les droits.

Maintenant (en tout cas, c'est le but), dbus c'est un IPC, hal (bientot devicekit ), c'est le matos et les droits peuvent être définis de manière homogènes dans policykit et consolekit s'occupe de détecter la nature de la session, plus KISS que ça, tu meurs, non ?

Ah oui, se taper des fichiers xml à la main et des commandes hal/*kit avec des options de 10km de long c’est vachement KISS
Je suis sans doute mauvaise langue…

Voilà, j'espère avoir éclairci

Oui, merci, ça éclaircit un peu plus…

Bon, faut que je RTFM un peu plus c’est sûr, c’est un concept que j’ai du mal à assimiler encore (déjà que j’ai du mal avec dbus )…
Ouais donc policykit permet de faire plus souplement la gestion des droits que ce que faisait (fait?) dbus.
En tout cas ta page wiki fait un peu peur tuxce

À savoir ensuite si j’en aurait l’utiliter à l’avenir (en tout cas, je sais que awesome se la joue dbus). À voir, À voir…

Merci à vous deux en tout cas

[mimas]

Lapin qu'on prie ?

Voilà, au lieu de mettre des privilèges à l'application A on va lui donner ou non le droit de communiquer avec le module B, module qui a des privilèges.

Dans le cas d'un gestionnaire de paquets, il n'y aura que la partie d'installation et téléchargement qui bénéficiera des privilèges root, pas le reste du code. Pas de "su" sur tout le code, donc potentiellement moins de problème de sécurité. Il faudrait que je regarde comment ils ont fait chez Pardus, ils ont fait du bon boulot, semble-t-il, pour intégrer les *Kit.

En ce qui concerne les problèmes de disposition de clavier, je suis tenté de répondre oui.

[marc[i1]]

Je tiens à remercier gyo pour avoir posé une question intelligente ( c’est rare )

[tuxce]

Finalement comme sudo sans la couche hal/dbus quoi

sudo lance une commande et non une méthode.

sans vouloir fuder, est-ce que *kit aurait à voir avec certaines personnes qui ont actuellement des problème de mappage clavier avec certaines applications ?

aucune idée car je n'arrive pas à le reproduire et je n'ai pas vu de ticket passer à ce sujet.

TM --> ™ (cadeau, celà dit on peut le faire en fr/oss )

comment ? (moi aussi je voudrais le faire )

Ah oui, se taper des fichiers xml à la main et des commandes hal/*kit avec des options de 10km de long c’est vachement KISS
Je suis sans doute mauvaise langue…

sans doute car de toute façon, dbus/hal, c'est de l'xml et pour les commandes, les options de setfacl ou autre n'ont rien à leur envier en longueur, et puis, une:

Code : Tout sélectionner

polkit-auth --user tuxce --grant org.freedesktop.hal.storage.mount-fixed

je pense que rien qu'en la lisant sans savoir ce qu'est policykit, tu sais déjà ce qu'elle fait (bon ok, il faut connaitre "grant", mais bon c'est courant comme mot)

Ouais donc policykit permet de faire plus souplement la gestion des droits que ce que faisait (fait?) dbus.

La sécurité sous dbus (en schématisant) est spécifique aux appels, en gros tu interdis ou tu autorises l'appel à la fonction de montage (par exemple), avec policykit, tu autorises par exemple les disques externes tout en interdisant les internes.

En tout cas ta page wiki fait un peu peur tuxce

elle ne demande qu'à s'améliorer, par contre, il faudrait m'en dire plus.

[marc[i1]]

TM --> ™ (cadeau, celà dit on peut le faire en fr/oss )

comment ? (moi aussi je voudrais le faire )

AltGr + Shift + 8

[tuxce]

ah oui ™
du coup je découvre tout un mode du clavier que je connaissais pas Þ
je vais pouvoir foutre en l'air mon aggrégateur avec mes posts aussi

[Guldano]

Bonjour à tous,

Je trouve ConsoleKit et PolicyKit très intèrressant, mais je ne comprend pas très bien non plus comment ça fonctionne.

Dans le wiki les méthodes pour lancer ConsolKit ne sont que pour les session graphique, est-ce que l'on peut l'utiliser en console aussi ?

Est-ce que ses systèmes peuvent remplacer sudo car la directive policyKit :

Code : Tout sélectionner

<config version="0.1">
  <define_admin_auth group="wheel"/>
</config>

ma l'air d'avoir la même fonctionnalité que la directive sudo :

Code : Tout sélectionner

%wheel ALL=(ALL) ALL

merci

[tuxce]

salut,

Je trouve ConsoleKit et PolicyKit très intèrressant, mais je ne comprend pas très bien non plus comment ça fonctionne.

faudrait préciser la question sinon, la seule réponse que je vois est le paragraphe fonctionnement/principe dans le wiki...

Dans le wiki les méthodes pour lancer ConsolKit ne sont que pour les session graphique, est-ce que l'on peut l'utiliser en console aussi ?

les 2 dernières méthodes du wiki fonctionnent aussi en console:
- lancer ck-launch-session dans un .bash_profile par exemple
- ajouter la ligne "pam" à la fin de /etc/pam.d/login

mais pour l'instant, consolekit suppose qu'une session non graphique n'est pas active (cf wiki pour active/pas active)

Est-ce que ses systèmes peuvent remplacer sudo

non car pour sudo, c'est l'administrateur (en gros, toi ) qui décide quels programmes sont permis à tel utilisateur, alors que pour policykit, c'est d'abord l'application (hal, gnome-power etc...) qui décide quelle méthode peut être lancée en mode privilégié et tu n'as le choix que dans la modification des autorisations.

[Guldano]

je comprends un peut mieux leurs utilité, en fait c'est surtout destiné aux programmeurs pour pouvoir gérer les droits sur certaines partie du système sans devoir lancer toutes l'application en tant que root.

L'utilisateur ou l'administrateur ne devrait donc pas avoir besoin de modifier les fichiers de configuration.

Pour les programmeurs je comprends pas vraiment comment il peut l'utiliser, est-ce utilisable dans toutes les languages de programmation (y compris bash), car je suppose que pour pouvoir utiliser polkit-auth et polkit-action il faut être root.

Dans le wiki il y a quelque phrase que j'ai pas bien compris par exemple :

Code : Tout sélectionner

Sans l'utilisation de ConsoleKit, le dernier utilisateur connecté à une session graphique a la main mise sur tout le matériel accessible par l'utilisateur

Je ne vois pas pourquoi il aurait la main mise sur tout le matériel, surtout le dernier utilisateur, le premier est-il plus limiter ?

Si j'ai bien compris la session ConsoltKit n'a rien à voir avec une session utilisateur, mais plutôt avec le lancement de X, si plusieurs utilisateurs se connecte et se déconnecte avec gdm il reste dans la même session ConsoleKit .

Désolé c'est un peut confu, je n'arrive pas bien à expliqer mais je trouve que les nouvelles technologies (udev, hal, dbus, ...) sont compliquées ou plutot mâl expliquée dans leur ensemble.

[gyo]

je comprends un peut mieux leurs utilité, en fait c'est surtout destiné aux programmeurs pour pouvoir gérer les droits sur certaines partie du système sans devoir lancer toutes l'application en tant que root.

L'utilisateur ou l'administrateur ne devrait donc pas avoir besoin de modifier les fichiers de configuration.

Je vois pas le rapport avec de la programmation, c’est justement le boulot de l’administrateur que de gérer les droits et d’ailleurs si tu regardes bien dans le wiki, il y a des GUI pour gérer les droits avec policykit…

Désolé c'est un peut confu, je n'arrive pas bien à expliqer mais je trouve que les nouvelles technologies (udev, hal, dbus, ...) sont compliquées ou plutot mâl expliquée dans leur ensemble.

Ben c’est pas comme si il y avait pas de ressources de documentation sur ces sujets sur le net (certes, la plupart des ressources sont en anglais). Et tuxce fait ce qu’il peut pour mettre ça au clair
Le tout c’est de prendre le temps de se documenter…

[tuxce]

L'utilisateur ou l'administrateur ne devrait donc pas avoir besoin de modifier les fichiers de configuration.

comme tout, si le "par défaut" convient, pas besoin de modifier...

est-ce utilisable dans toutes les languages de programmation (y compris bash)

pas compris à la question !
depuis quand bash a une api ?
il fait appel à des commandes !!

Dans le wiki il y a quelque phrase que j'ai pas bien compris par exemple :

Code : Tout sélectionner

Sans l'utilisation de ConsoleKit, le dernier utilisateur connecté à une session graphique a la main mise sur tout le matériel accessible par l'utilisateur

Je ne vois pas pourquoi il aurait la main mise sur tout le matériel, surtout le dernier utilisateur, le premier est-il plus limiter ?

tu as raison, c'est pas forcément le dernier, je vais modifier ça.
dans les faits, tu montes une partition, un autre utilisateur ne peut la démonter, le dernier serveur de son lancé contrôle le périphérique de son etc...

Code : Tout sélectionner

Si j'ai bien compris la session ConsoltKit n'a rien à voir avec une session utilisateur, mais plutôt avec le lancement de X, si plusieurs utilisateurs se connecte et se déconnecte avec gdm il reste dans la même session ConsoleKit .

non.

bref, le reste -> (cf. doc)

[cassyb]

j'ai fait une grosse maj et j'ai rencontré le problème d'hal qui ne voulait plus que je monte mon disque dur externe, éteindre la machine, etc...
J'ai résolu le problème en mettant simplement dans .xinitrc

Code : Tout sélectionner

exec ck-launch-session startxfce4

comme précisé dans le wiki.
Là tout marche comme avant, je n'ai pas eu besoin de créer des règles pour le user.
Je n'ai pas eu à ajouter:

Code : Tout sélectionner

<define_admin_auth group="wheel"/>

Mon /etc/Policykit/Policykit.conf est vide (tel qu'il est par défaut)

...
<config version="0.1">
</config>

Est-ce que le fait qu'il soit vide donne par défaut tous les droits à tous les users?
En fait dans mon cas, je n'ai pas compris la nécessité d'ajouter:

Code : Tout sélectionner

<define_admin_auth group="wheel"/>

[tuxce]

Est-ce que le fait qu'il soit vide donne par défaut tous les droits à tous les users?

j'ai rajouté un complément dans la section fonctionnement: http://wiki.archlinux.fr/systeme/policy ... tionnement
Les actions et autorisations par défaut sont dans /usr/share/PolicyKit/policy

En fait dans mon cas, je n'ai pas compris la nécessité d'ajouter:

Code : Tout sélectionner

<define_admin_auth group="wheel"/>

je dis nulle part qu'il faut le rajouter (enfin si tu t'es basé sur le wiki), c'est un exemple !
pour des actions demandant des privilèges administrateur le mot de passe demandé sera celui du root par défaut, à part si une directive "define_admin_auth" est présente et dans ce cas, le mot de passe sera celui de l'utilisateur mentionné ou un utilisateur du groupe indiqué.