C’est dit dans le man, xauth est un programme gérant les autorisations de connexion au serveur X11. Il est désigné comme le remplaçant de xhost, qui était bien permissif et bien connu pour les détournements de X11.

xauth utilise un fichier qui contient une liste de display names associés à des nombres en hexadécimal qui représentent le magic cookie. Ce fichier est soit sous ~/.Xauthority, soit, lorsque l’utilisateur courant utilise un gestionnaire de fenêtre,  sous l’arborescence de run du gestionnaire. Par exemple, pour Gnome, le fichier est sous /var/run/gdm3/auth-for-bux-*/ et se nomme database.

Le principe est simple : les applications clientes requêtant le serveur X11 lisent et fournissent ce magic cookie, et si la valeur est conforme à celle que le serveur X11 a en mémoire, alors le client est autorisé à ouvrir une fenêtre sur le serveur X11. Vu que le .Xauthority a des permissions en 600, il est théoriquement impossible pour quelqu’un d’autre de lire et d’utiliser ce magic cookie.

Pour voir le contenu du .Xauthority, on peut le cat ou tout simplement utiliser xauth pour nous afficher ce qu’il a dans le ventre :

[bux@lab~]# xauth list
lab/unix:10    MIT-MAGIC-COOKIE-1 1b3f3b17eae0702b9d1972054d857159

[bux@lab~]# xauth info
Authority file:    /var/run/gdm3/auth-for-bux-03kwJ9/database
File new:          no
File locked:       no
Number of entries: 1
Changes honored:   yes
Current input:     (argv):1

En local, pour l’utilisateur, il n’y a donc pas de problème. Là où il faut jouer, c’est lorsque l’utilisateur choisit de solliciter le X11 d’un poste distant, ou bien que l’utilisateur passe root en local en jouant avec su. En effet, il faut alors propager ce magic cookie afin qu’il puisse toujours utiliser le X11.

2 méthodes pour cela. Toutes les 2 partent du même point : il faut récupérer le magic cookie.

La première méthode concerne le cas de figure où, par exemple, l’utilisateur souhaite juste utiliser le X11 d’une machine distante. Pour ce faire, il lui faut extraire les données d’autorisation et les propager à l’hôte distant. Fait simplement, ça donne ça :

[bux@lab~]# xauth extract - lab/unix:10 | ssh remotelab xauth merge -

Comme le Xauthority est en 600, seul l’utilisateur en question ou root peut utiliser merge.

La seconde méthode est plus dans l’optique d’un su – de l’utilisateur qui souhaiterait du coup continuer à utiliser les services du X11 de l’hôte sur lequel il est connecté. Le merge fonctionne aussi, mais comme on sait déjà le faire, on va plutôt jouer avec add :

[bux@lab~]# xauth add lab/unix:10 MIT-MAGIC-COOKIE-1 1b3f3b17eae0702b9d1972054d857159

Après le add, et vu qu’on est toujours sur le même host, et qu’on a juste su – , il suffit alors d’exporter le DISPLAY conformément à ce qu’il y a dans le Xauthority :

[root@lab~]# export DISPLAY= localhost:10

And voilà…

[Photo par Jeroen Bennink]

Original post of K-Tux.Votez pour ce billet sur Planet Libre.