Bonjour à tous, Je découvre sur le forum d'une autre distro les possibilités qu'une commande soit "bridée" par une modification de ses "Capabilities", et donc qu'on puisse la "débrider". C'est bien expliqué ici. Ça pourrait rendre service à d'autres non-informaticiens comme moi à l'occasion... Bon Dimanche.
cet article date quand même de 2010, la plupart des distributions a évolué vers d'autres solutions...
le problème, c'est que même si on donne des permissions supplémentaires (ou qu'on en enlève) à un processus en cours d'utilisation, on a toujours le même problème: ces permissions sont accordées, et peuvent donc être exploitées (en bien ou en mal).
on a aujourd'hui des solutions plus sécures, qui soit accordent des permissions en fonction de règles prédéfinies à certains groupes d'utilisateurs sur identification (Policykit), soit exécutent à la place de l'utilisateur les fonctions pour lesquelles il n'a pas les droits, sur la base de règles prédéfinies (Dbus).
d'ailleurs, si on regarde ceci, on y voit une liste des binaires setuid root; si on compare avec ce qu'on obtient avec cette commande:
find /usr/bin /usr/lib -perm /4000 -user root
on s'aperçoit que la liste des binaires qui ont cette ancienne autorisation est en baisse...
Asus AIO - AMD E2 - Radeon HD 7340 - Manjaro 64 + Kf5 + Linux 3.14
explication: logiquement, seul Root a le droit d'arrêter la machine; pour que le simple utilisateur puisse arrêter la machine, il demande au serveur Dbus, via le client, l'exécution d'une règle bien précise d'arrêt de la machine (org.freedesktop.ConsoleKit.Manager.Stop); c'est très sécurisé, car la règle est définie à l'avance d'une part, et l'utilisateur doit connaitre la règle à invoquer auprès de Dbus. avant ça, pour arrêter la machine, la commande "shutdown -h" nécessitait d'être Root (soit directement, soit grâce à Sudo); grâce à Dbus, ce n'est plus nécessaire. d'ailleurs, pour ceux qui se font des environnements avec des scripts ou des menus perso (comme avec Openbox), je vous donne les autres commandes; plus haut, celle pour arrêter; celle pour redémarrer:
Puissant ! Les trois commandes fonctionnent parfaitement - la 1ère, après avoir installé consolekit-git par AUR - l'hibernation - qui me plantait auparavant - fonctionne parfaitement avec ta commande, je sens qu'il va y avoir un nouveau lanceur dans mon tableau de bord...
Consolekit n'est plus installé depuis un moment car obsolète ?
Warning: From ConsoleKit's web site: ConsoleKit is not actively maintained. The focus has shifted to the built-in seat/user/session management of systemd called systemd-loginctl.
oui, j'ai édité... effectivement, je n'avais pas calculé que Systemd changeait la donne à ce niveau (et les commandes viennent de mes vieux script pour Openbox et Icewm).
Asus AIO - AMD E2 - Radeon HD 7340 - Manjaro 64 + Kf5 + Linux 3.14
Toutes ces commandes sont efficaces et même impressionnantes: poweroff éteint la bécane instantanément, sans faire de dégâts (apparemment). Bon je désinstalle ConsoleKit.
au niveau de l'action effectuée, il ne devrait pas y avoir de différence; en revanche, Poweroff ou Shutdown doivent être lancé par Root (ou Sudo), tandis que "systemctl poweroff" peut être lancé par un simple utilisateur.
Asus AIO - AMD E2 - Radeon HD 7340 - Manjaro 64 + Kf5 + Linux 3.14
shutdown, c'est le vieux truc systemV. Ils le gardent pour des raisons de compatibilité, mais c'est tout. Maintenant, savoir comment c'est implémenté en-dessous... A leur place, je l'aurais branché sur le nouveau.
La grosse différence introduite par systemD, c'est la maîtrise totale des services. Avant, ils étaient lancés un peu n'importe comment (dans n'importe quel ordre selon les listes utilisateurs en général) alors que là, systemD connaît la totale et optimise cet ordre, ce qui ne peut aller qu'en s'améliorant.
Au niveau de l'arrêt; c'est encore plus frappant : au lieu d'essayer de retrouver les services qui tournent et des les arrêter tant bien que mal, systemD en a gardé d'un bout à l'autre la liste et les caractéristiques, donc peut les arrêter très sec, presque violemment.
Chez moi, c'est quasi-instantané. 1 à 2" après la frappe de cet ordre, j'entends le claquement du relais de ma tour. Ça défile encore un peu à l'écran le temps que les condensateurs se vident, mais c'est déjà fini.
Esclapion a écrit :La grosse différence introduite par systemD, c'est la maîtrise totale des services. Avant, ils étaient lancés un peu n'importe comment (dans n'importe quel ordre selon les listes utilisateurs en général) alors que là, systemD connaît la totale et optimise cet ordre, ce qui ne peut aller qu'en s'améliorant.
et surtout, des choses que SysVinit ne savait pas faire: -lancer plusieurs services en même temps, parallèlement (SysVinit les lançait l'un après l'autre): c'est surtout ça qui accélère le boot et l'arrêt. -établir un jeu de dépendances, un service dépendant d'un autre pour se lancer; par exemple, rien ne sert de lancer Ntpd avant Netctl. -gérer des permissions (avec Polkit); les services de SysVinit ne pouvaient être lancés que par Root, avec Systemd (comme on vient de le voir), un simple utilisateur peut avoir accès à certains services.
une des premières distributions à avoir utilisé Systemd était Frugalware, et c'était plutôt bluffant; maintenant ça se généralise (sauf Ubuntu qui persiste avec une solution maison), et même Debian est en train de s'y mettre (je crois même que la testing doit l'avoir, à confirmer).
Asus AIO - AMD E2 - Radeon HD 7340 - Manjaro 64 + Kf5 + Linux 3.14