Contournement d'autorité X

Question

J'essaie d'écrire une application qui s'exécute en tant que démon et qui surveille les sessions X exécutées . En ce moment j'ai du mal à trouver la documentation concernant le modèle de sécurité X. Plus précisément, je tente de se connecter aux écrans X en cours d'exécution à partir de mon processus démon. Appeler XOpenDisplay(dispName) ne fonctionne pas, je suppose que mon processus n'a pas la permission de se connecter à cet affichage. Après un peu de recherche, il semble que je doive faire quelque chose avec xauth.

Dans mon environnement de test, le serveur X est démarré comme ceci:

/usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-QBEVDj 

Ce fichier contient une seule entrée, qui ressemble à ceci:

#ffff##: MIT-MAGIC-COOKIE-1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 

en ajoutant une entrée à ~/.Xauthority avec la même clé hexadécimale, je peux se connecter au serveur X. Cependant, ceci est difficile parce que j'ai besoin de trouver par programme le fichier auth utilisé par le serveur X (l'emplacement deviendra probablement de distro à distro, et probablement d'un démarrage à l'autre), puis l'interroger, puis écrivez un nouveau fichier auth . Si le processus s'exécute en tant que démon, il peut ne pas avoir de répertoire personnel , alors comment savoir où écrire les nouvelles entrées?

Idéalement, ce que je suis à la recherche est un moyen de contourner la nécessité d'avoir le cookie xauth dans ~/.Xauthority, ou même de savoir ce que le cookie est à tous. Je me rends compte que cela est peu probable - à quoi bon un modèle de sécurité s'il est facilement contourné? mais j'espère que quelqu'un sur cette liste aura quelques bonnes idées. Existe-t-il un moyen de spécifier que mon processus est privilégié et devrait donc automatiquement avoir accès à n'importe quel affichage sur la machine locale?

Answer 1

Vous n'avez pas besoin d'utiliser un répertoire personnel si vous spécifiez une variable d'environnement XAUTHORITY, qui spécifie l'emplacement du fichier .Xauthority. Lisez la page de manuel xauth. Mais, en général, il est difficile de localiser le fichier auth, pour les raisons que vous avez mentionnées; De plus, cette approche de «pêche aux jetons authentiques» ne fonctionnerait que pour les expositions locales. En ce qui concerne le fait de laisser la racine (ou un autre utilisateur) se connecter à un serveur X, vous devrez probablement patcher le code source pour le faire, et vous devrez utiliser quelque chose comme getpeereid pour obtenir l'uid/gid de l'utilisateur qui se connecte (cela ne fonctionne que sur les sockets Unix-domain, ce qui, je présume, serait le type utilisé pour les connexions locales, de toute façon).

Answer 2

Xauth est pas le seul mécanisme de sécurité pour X

Il y a aussi un autre (moins sûr) qui effectue simplement l'authentification basée sur IP (Voir xhost). Par conséquent, si vous basculez votre serveur X vers ce mode moins sécurisé, il fera confiance aux connexions venant de l'ensemble d'adresses IP défini.

De cette façon, vous n'avez pas du tout besoin de traiter avec Xauthority.