sudo et tkinter ---> couldn't connect to display ":0"

Asikar · 04-11-2020 15:36:35

Bonjour,

j'ai un petit programme Test en python3 avec tkinter qui fonctionne très bien quand je l'exécute directement, mais pas avec sudo.

voici la version simplifiée du programme :

#!/usr/bin/python3

# -*- coding: utf-8 -*-

from tkinter import *

class Fen(Frame):

    def __init__(self):

        Frame.__init__(self)

        self.master.title('essai')

        self.master.geometry("300x300")

        self.pack()

if __name__ == '__main__' :

    Fen().mainloop()

et voici le message d'erreur que j'obtiens quand je l'exécute via la commande sudo Test :

No protocol specified

No protocol specified

Traceback (most recent call last):

  File "./Test", line 18, in <module>

    Fen().mainloop()

  File "./Test", line 11, in __init__

    Frame.__init__(self)

  File "/usr/lib/python3.7/tkinter/__init__.py", line 2744, in __init__

    Widget.__init__(self, master, 'frame', cnf, {}, extra)

  File "/usr/lib/python3.7/tkinter/__init__.py", line 2292, in __init__

    BaseWidget._setup(self, master, cnf)

  File "/usr/lib/python3.7/tkinter/__init__.py", line 2259, in _setup

    _default_root = Tk()

  File "/usr/lib/python3.7/tkinter/__init__.py", line 2023, in __init__

    self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use)

_tkinter.TclError: couldn't connect to display ":0"

Je précise que je suis sous gnome 3.30 (avec Wayland) mais que je ne connais pas grand chose au fonctionnement de serveur X, d'export display ...

Merci pour toute aide.

David5647 · 04-11-2020 15:43:32

Normalement root n'a pas accès à l'environnement graphique,
il doit y avoir le moyen de contourner cela, mais ce n'est pas vraiment une "bonne pratique".
Que souhaites tu faire exactement? Quelle action nécessitant l'accès "root" souhaites tu effectuer?

Dernière modification par David5647 (04-11-2020 15:44:24)

vv222 · 04-11-2020 17:23:25

Cette commande autorise le compte root à accéder à la session graphique de l’utilisateur courant :

xhost +si:localuser:root

Ensuite, pour révoquer cet accès :

xhost -si:localuser:root

---

Même si cette possibilité existe, je suis plutôt d’accord avec David5647 sur son conseil d’éviter de lancer des applications ayant accès au serveur graphique via le compte root.

Asikar · 04-11-2020 17:43:14

Je cherche à donner, au sein d'un petit réseau local, quelques droits d'administration à un groupe d'utilisateur (comme par exemple éteindre ou allumer tous les postes d'une salle)
L'idée est de leur permettre de le faire via une petite application graphique (d'où tkinter), puis donner la permission d'exécuter ce script en root (via sudoers).
je précise que le petit réseau n'est pas très "sensible" ni très exposé en terme de sécurité.

J'ai essayé la commande

xhost +si:localuser:root

qui me renvoie

localuser:root being added to access control list

X Error of failed request:  BadValue (integer parameter out of range for operation)

  Major opcode of failed request:  109 (X_ChangeHosts)

  Value in failed request:  0x9

  Serial number of failed request:  7

  Current serial number in output stream:  9

mais qui ne permet toujours pas d'éxécuter le programme Test avec sudo (même message d'erreur).

J'avoue ne rien comprendre à ce nouveau message d'erreur ... :-(

Merci pour l'aide.

vv222 · 04-11-2020 19:06:31

Asikar a écrit :

localuser:root being added to access control list
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 109 (X_ChangeHosts)
Value in failed request: 0x9
Serial number of failed request: 7
Current serial number in output stream: 9

Je ne vais pas pouvoir aider là-dessus, j’ai testé la commande xhost sur plusieurs Debian à ma disposition et aucune ne m’a renvoyé d’erreur dans ce style.

David5647 · 04-11-2020 22:35:33

Bon, j'en sais pas plus sur xhost : jamais utilisé.

Je ne sais pas non plus comment outrepasser ce problème d' "interface graphique en root".
Dans les applications que l'on croise c'est souvent polkit/policykit qui est utilisé. Je ne sais pas si ça fonctionne avec wayland. Je ne sais pas si c'est difficile a implémenter...

Tu peux peut-être essayer d'ajouter l'utilisateur à un groupe qui aurait ces droits d'accès pour le réseau!?

Ou encore : ouvrir un terminal, y lancer la commande et laisser l'utilisateur entrer le mot de passe!? Là encore, jamais tenté...

Dernière modification par David5647 (04-11-2020 22:36:19)

Asikar · 05-11-2020 14:14:00

Bonjour,

je rectifie : vv222, ta commande

xhost +si:localuser:root

fonctionne bien. C'est moi qui l'avait mal utilisée (j'avais compris que localuser représentait mon nom d'utilisateur, et pas qu'il s'agissait d'un mot clef ...)
Merci donc, ça marche maintenant !

Par rapport aux réserves émises sur le fait de donner un accès root au serveur graphique, qu'elle méthode serait préférable pour mettre à la disposition d'un groupe d'utilisateurs, une application graphique capable d'effectuer qqes commandes d'administration ?
Je sais le faire en ligne de commande (avec un script bash et le fichier /etc/sudoers) mais il y a des personnes à qui la ligne de commande fait peur ....

David5647 · 05-11-2020 15:57:53

Il y a sûrement de nombreux arguments à l'encontre d'un accès par root au serveur graphique,
De ce que j'en retiens, généralement, dans le monde linuxien, le parti-pris est de monter en privilèges uniquement lorsque cela est nécessaire.
Toujours pour préserver la racine d'une erreur de manipulation*, d'un bug, voire d'une application malveillante.
C'est simplement plus "risqué, mais pas catastrophique pour le système, c'est une recommandation. (enfin je le vois comme ça).

C'est un peu la philosophie de sudo : on exécute l'action nécessaire avec les droits root et on révoque ces droits aussitôt.
Pour une application graphique, comme cité en #6, on peut utiliser policykit,
que le wiki debian qualifie de :

It is sometimes referred to as "the sudo of systemd".

L'idée étant de monter en privilèges uniquement pour la partie du programme qui nécessite des droits supplémentaires et non pour la globalité de l'interface.
Le programme virt-manager passe par exemple par ce système.

Bref, je suppose que c'est la méthode recommandée, en tout cas, celle à laquelle je suis confronté dans la pratique.

*Je pense que c'est l'argument premier : Protéger l'utilisateur de l'utilisateur.
De plus, une application destinée à être exécutée en root mérite un design particulier : par exemple demander confirmation avant enregistrement.

Dernière modification par David5647 (05-11-2020 16:02:24)

Debian-facile

#1 04-11-2020 15:36:35

sudo et tkinter ---> couldn't connect to display ":0"

#2 04-11-2020 15:43:32

Re : sudo et tkinter ---> couldn't connect to display ":0"

#3 04-11-2020 17:23:25

Re : sudo et tkinter ---> couldn't connect to display ":0"

#4 04-11-2020 17:43:14

Re : sudo et tkinter ---> couldn't connect to display ":0"

#5 04-11-2020 19:06:31

Re : sudo et tkinter ---> couldn't connect to display ":0"

#6 04-11-2020 22:35:33

Re : sudo et tkinter ---> couldn't connect to display ":0"

#7 05-11-2020 14:14:00

Re : sudo et tkinter ---> couldn't connect to display ":0"

#8 05-11-2020 15:57:53

Re : sudo et tkinter ---> couldn't connect to display ":0"

Pied de page des forums