Comment résoudre «Aucun protocole spécifié» pour l'utilisateur su

J'essaie d'utiliser un autre utilisateur (non administrateur) pour exécuter un logiciel graphique sur mon système. Cet autre utilisateur a été nommé et a reçu un UID et un GID pour correspondre à un utilisateur système distant du même nom. L'UID est de 500, donc je crois que cela fait de l'utilisateur un utilisateur «sans connexion».

À partir d'Ubuntu connecté à mon compte principal, j'ouvre un terminal et suà l'utilisateur alternatif. J'essaie ensuite d'exécuter la commande pour démarrer l'application et recevoir «Aucun protocole spécifié».

Est-ce à cause de l'UID <1000, à cause de suou à cause du non-administrateur de l'utilisateur? Comment puis-je demander à cet utilisateur d'exécuter l'application avec une interface graphique?

Le problème ne se produit pas en raison de l'UID de l'utilisateur. 500 est très bien en tant qu'UID, et cet UID n'en fait pas un utilisateur `` sans connexion '', sauf aux yeux des paramètres par défaut de quelques gestionnaires d'affichage.

Le message d'erreur Aucun protocole spécifié ne ressemble à un message d'erreur spécifique à l'application, et inutile à cela, mais je vais deviner que l'erreur est que l'application est incapable de contacter votre écran X11 car elle n'a pas l'autorisation de le faire parce qu'il fonctionne en tant qu'utilisateur différent. Les applications ont besoin d'un "cookie magique" (jeton secret) pour parler au serveur X11 afin que les autres processus du système exécutés par d'autres utilisateurs ne puissent pas empiéter sur votre affichage, créer des fenêtres et espionner vos frappes. L'autre utilisateur du système n'a pas accès à ce cookie magique car les autorisations sont définies de sorte qu'il n'est accessible qu'à l'utilisateur qui a démarré l'environnement de bureau (ce qui devrait être le cas).

Essayez ceci, en tant qu'utilisateur d'origine, pour copier le cookie X11 sur l'autre compte:

su - <otheruser> -c "unset XAUTHORITY; xauth add $(xauth list)"

puis exécutez votre application. Vous devrez peut-être également désactiver XAUTHORITYce shell. Cette commande extrait le cookie magique ( xauth list) de votre utilisateur principal et l'ajoute ( xauth add) à l'endroit où l'autre utilisateur peut l'obtenir.

Je mon cas, le nouveau serveur d'affichage waylandétait le problème,

il suffit xhost + local:alors que les autres utilisateurs (par exemple root) soient autorisés à exécuter Programms dans votre session, les connexions réseau ne seront cependant pas autorisées.

Si vous souhaitez autoriser les clients de n'importe quel hôte , vous pouvez utiliser xhost +sans spécifier d'hôte du tout. Ceci n'est cependant pas sûr , il serait préférable de simplement spécifier les hôtes pour lesquels vous souhaitez accorder l'accès à votre session.

Essayez quelque chose comme ça

$ export LOGIN_USER="Math"
$ su - $LOGIN_USER
$ sudo xhost local:$LOGIN_USER &>/dev/null

la source

Ps : la réponse acceptée n'a pas fonctionné pour moi

Supposons que vous vouliez forcer une connexion brute avec X ...

Supposons que vous exécutez déjà vos commandes sur le serveur (où X s'exécute), sinon faites en sorte que cela fonctionne d'abord, puis utilisez 'ssh -X user @ server) à partir du client par la suite;).

Il peut y avoir plusieurs façons d'exécuter les commandes xauth, par exemple, vous pouvez utiliser «sudo», mais cela peut perdre ou modifier les variables d'environnement. Les variables d'environnement suivantes doivent être préservées: DISPLAY et XAUTHORITY. Pour tester si c'est le cas, vous pouvez exécuter 'echo $ XAUTHORITY' de la même manière que vous exécutez vos commandes, mais assurez-vous de ne pas étendre les variables d'environnement avant d'exécuter ces commandes. Par exemple, essayez: sudo bash -c 'echo "$ XAUTHORITY"' pour voir ce qu'est vraiment XAUTHORITY après avoir exécuté votre sudo (s'il disparaît, vous devrez peut-être ajouter quelque chose à votre fichier sudoers, voir ailleurs).

Finalement, exécutez la commande suivante en tant qu'utilisateur avec lequel vous souhaitez accéder, sur le serveur:

xauth info

Cela montrera le «fichier d'autorité» qui sera utilisé (/root/.Xauthority par défaut, pour root, ou quelque chose comme /home/theuser/.Xauthority). S'il affiche le fichier .Xauthority correct, vous n'avez pas à vous soucier de la variable d'environnement XAUTHORITY en fait (en fait, je ne saurais pas quand il ne le ferait pas, sauf si vous voulez manipuler un emplacement non standard de ce fichier ).

Supprimez ce fichier (s'il existe même):

rm /root/.Xauthority

Remplacez-le /root/.Xauthoritypar le fichier XAUTHORITY correspondant à votre cas.

Recréez-le, mais vide (cela est nécessaire pour de nombreuses commandes):

touch /root/.Xauthority

À ce stade, vous obtiendrez l' erreur Aucun protocole spécifié , même si vous avez déjà obtenu MIT-MAGIC-COOKIE-1 non valide . Recherchez le fichier d'autorité que le serveur X utilise actuellement:

ps aux | grep Xorg

Cela devrait montrer quelque chose comme:

root 1153 0.0 1.0 149560 44464 tty7 Ss+ dec02 0:00 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711} -background none -noreset -displayfd 17 vt7

Le nom du fichier après -authest celui dont vous avez besoin dans la commande suivante. Exécutez ceci en tant que root:

sudo xauth -f '/var/run/sddm/{ef18c483-7891-4e82-80ef-2c8f9bd79711}' list

Cela répertorie une clé hexadécimale à 32 chiffres. Par exemple, la sortie pourrait être:

hostname/unix:0 MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

Utilisez-le pour générer votre fichier .Xauthority (en tant qu'utilisateur qui doit se reconnecter):

xauth add $DISPLAY MIT-MAGIC-COOKIE-1 c0eaf749aa252101a0f57d5087089db7

remplacez «c0eaf749aa252101a0f57d5087089db7» par ce qui vous a été renvoyé par la commande list. Votre .Xauthority devrait maintenant avoir une taille de 51 octets et vous pouvez vous connecter au serveur X (à nouveau).

J'ai eu cette erreur «Aucun protocole spécifié» lorsque j'ai démarré une instance de Selenium 3.3.1 à partir d'un script parvenu puis utilisé le pilote Chrome dans Selenium. Selenium s'exécutait avec le même utilisateur que X11 et la variable d'environnement du shell DISPLAY était correctement définie. Ce qui est intéressant, c'est que cette erreur ne s'est pas produite lorsque j'ai utilisé le pilote Firefox. La définition de la variable d'environnement shell XAUTHORITY dans le script upstart pour pointer vers la valeur de $ XAUTHORITY de l'utilisateur X11 actif a corrigé l'erreur pour le pilote Chrome.

Sur une note latérale, l'erreur "Aucun protocole spécifié" a été complètement enterrée par le pilote Chrome / Chrome et n'était en aucun cas facile à trouver. J'ai remarqué que Chrome continuait à créer des répertoires dans le modèle de /tmp/.org.chromium.Chromium.*, mais ils disparaissaient rapidement. J'ai réussi à remarquer qu'ils contenaient un fichier chrome_debug.logqui avait un message "Impossible d'ouvrir l'affichage". J'ai pensé que c'était plutôt étrange car j'ai vérifié que le processus de sélénium avait le bon AFFICHAGE /proc/$pid/environet j'ai examiné straceplus en détail la sortie du processus de sélénium, ce qui a révélé "Aucun protocole spécifié" m'amenant finalement à cette question.

Cette erreur peut être reproduite en désactivant XAUTHORITY et en essayant d'exécuter un client X11. Par exemple:

$ XAUTHORITY= xeyes
No protocol specified
Error: Can't open display: :0.0

C'était simple. Le problème se produit lorsque vous êtes dans sate racine et que vous voulez utiliser le gksu juste quitter l'état racine et essayez à nouveau

Tapez simplement ceci dans votre terminal xhost +SI:localuser:rootaprès avoir tapé export DISPLAY=:0.0puis réessayez

En utilisant des indices dans les réponses acceptées, j'ai pu résoudre le problème différemment:

1. Recherchez le fichier Xauth dans le compte qui fonctionne (Xauth1)
2. Recherchez le fichier Xauth dans le compte qui ne le fait pas (Xauth2)
3. Copiez Xauth1 vers Xauth2
4. Modifier les autorisations de Xauth2

Dans du code:

root@45c4933a8f1a:~# xauth info
Authority file:       /headless/.Xauthority
<snip>
root@45c4933a8f1a:~# su OtherUser
OtherUser@45c4933a8f1a:/headless$ xauth info
Authority file:       /home/OtherUser/.Xauthority
<snip>
OtherUser@45c4933a8f1a:/headless$ exit
exit
root@45c4933a8f1a:~# cp /headless/.Xauthority /home/OtherUser/.Xauthority 
root@45c4933a8f1a:~# chown OtherUser:OtherUser /home/OtherUser/.Xauthority
root@45c4933a8f1a:~# su OtherUser

Laissez vous dit essayez d'accéder à l' interface graphique comme utilisateur2 ( utilisateur normal ), alors vous devez charger l' interface utilisateur d'installation comme utilisateur2 .

Essayez de suivre ceci:

Connectez-vous en tant que root :

sudo su

Testez le serveur x:

xclock

Si vous pouvez voir une horloge fonctionner, c'est bon, essayez maintenant d'exécuter ceci:

xhost

Le résultat devrait ressembler à ceci:

xhost SI:localuser:tri
# tri is my user name

Maintenant, laissez user2 accéder à xhost

xhost +SI:localuser:user2

essayez maintenant de vous connecter à nouveau à user2 et essayez d'ouvrir n'importe quel programme GUI.