So lösen Sie "Kein Protokoll angegeben" für su-Benutzer auf

Ich versuche, einen alternativen Benutzer (Nicht-Administrator) zum Ausführen von Grafiksoftware auf meinem System zu verwenden. Dieser alternative Benutzer wurde benannt und mit einer UID und einer GID versehen, die einem gleichnamigen Remote-Systembenutzer entsprechen. Die UID ist 500, daher glaube ich, dass der Benutzer ein Benutzer ist, der sich nicht anmeldet.

Ausgehend von Ubuntu, das in meinem Hauptkonto angemeldet ist, öffne ich ein Terminal und wende mich suan den alternativen Benutzer. Ich versuche dann, den Befehl auszuführen, um die Anwendung zu starten und "Kein Protokoll angegeben" zu erhalten.

Liegt das an der UID <1000, am suoder am Nichtadministrator des Benutzers? Wie kann ich diesen Benutzer dazu bringen, die Anwendung mit einer GUI auszuführen?

Das Problem wird nicht auftreten , weil die Benutzer - ID des Benutzers. 500 ist als UID in Ordnung, und diese UID macht es nicht zu einem "Nicht-Login" -Benutzer, außer in den Augen der Standardeinstellungen einiger weniger Display-Manager.

Die Fehlermeldung Kein angegebenes Protokoll klingt wie eine anwendungsspezifische Fehlermeldung, und zwar eine nicht hilfreiche, aber ich gehe davon aus, dass der Fehler darin besteht, dass die Anwendung nicht in der Lage ist, Ihr X11-Display zu kontaktieren, weil sie keine Berechtigung dazu hat Also, weil es als ein anderer Benutzer ausgeführt wird. Anwendungen benötigen ein "Magic Cookie" (geheimes Token), um mit dem X11-Server zu kommunizieren, damit andere Prozesse auf dem System, die unter anderen Benutzern ausgeführt werden, nicht in Ihr Display eindringen, Fenster erstellen und Ihre Tastatureingaben abhören können. Der andere Systembenutzer hat keinen Zugriff auf dieses Magic Cookie, da die Berechtigungen so festgelegt sind, dass nur der Benutzer darauf zugreifen kann, der die Desktop-Umgebung gestartet hat (wie es sein sollte).

Versuchen Sie Folgendes, indem Sie als Ihr ursprünglicher Benutzer das X11-Cookie auf das andere Konto kopieren:

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

Führen Sie dann Ihre Anwendung aus. Möglicherweise müssen Sie XAUTHORITYdiese Shell auch deaktivieren. Dieser Befehl extrahiert das Magic Cookie ( xauth list) von Ihrem Hauptbenutzer und fügt es ( xauth add) dort hinzu , wo der andere Benutzer es erhalten kann.

Ich mein Fall der neue Display-Server waylandwar das Problem,

Tun Sie dies einfach, xhost + local:dann dürfen andere Benutzer (z. B. root) Programme in Ihrer Sitzung ausführen. Netzwerkverbindungen sind jedoch nicht zulässig.

Wenn Sie Clients von einem beliebigen Host zulassen möchten , können Sie sie verwenden, xhost +ohne überhaupt einen Host anzugeben. Dies ist jedoch unsicher . Es ist besser, nur die Hosts anzugeben, für die Sie Zugriff auf Ihre Sitzung gewähren möchten.

Angenommen, Sie möchten mit Gewalt eine Verbindung zu X herstellen ...

Nehmen wir an, Sie führen Ihre Befehle bereits auf dem Server aus (auf dem X ausgeführt wird), andernfalls lassen Sie dies zuerst funktionieren und verwenden anschließend 'ssh -X user @ server' vom Client.

Es gibt möglicherweise mehrere Möglichkeiten, die xauth-Befehle auszuführen. Sie verwenden beispielsweise möglicherweise 'sudo', dabei können jedoch Umgebungsvariablen verloren gehen oder geändert werden. Die folgenden Umgebungsvariablen müssen beibehalten werden: DISPLAY und XAUTHORITY. Um zu testen, ob dies der Fall ist, können Sie 'echo $ XAUTHORITY' auf die gleiche Weise wie Ihre Befehle ausführen, aber stellen Sie sicher, dass Sie die Umgebungsvariablen nicht erweitern, bevor Sie diese Befehle ausführen. Versuchen Sie zum Beispiel: sudo bash -c 'echo "$ XAUTHORITY"', um zu sehen, was XAUTHORITY wirklich ist, nachdem Sie Ihr sudo ausgeführt haben (wenn es verschwindet, müssen Sie möglicherweise etwas zu Ihrer sudoers-Datei hinzufügen, siehe an anderer Stelle).

Führen Sie schließlich den folgenden Befehl als den Benutzer auf dem Server aus, mit dem Sie Zugriff erhalten möchten:

xauth info

Dies zeigt die 'Authority-Datei' an, die verwendet wird (/root/.Xauthority standardmäßig für root oder so ähnlich wie /home/theuser/.Xauthority). Wenn die richtige .Xauthority-Datei angezeigt wird, müssen Sie sich keine Gedanken über die Umgebungsvariable XAUTHORITY machen (eigentlich würde ich nicht wissen, wann dies nicht der Fall ist, es sei denn, Sie möchten einen nicht standardmäßigen Speicherort dieser Datei bearbeiten ).

Entfernen Sie diese Datei (falls vorhanden):

rm /root/.Xauthority

Ersetzen Sie /root/.Xauthoritydurch die richtige XAUTHORITY-Datei für Ihren Fall.

Erstellen Sie es neu, aber leer (dies wird für viele Befehle benötigt):

touch /root/.Xauthority

Zu diesem Zeitpunkt wird der Fehler " Kein Protokoll angegeben" angezeigt, auch wenn Sie zuvor " Ungültiges MIT-MAGIC-COOKIE-1" erhalten haben. Suchen Sie die Berechtigungsdatei, die der X-Server derzeit verwendet:

ps aux | grep Xorg

Dies sollte ungefähr so ​​aussehen:

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

Der Dateiname danach -authist der Name, den Sie im nächsten Befehl benötigen. Führen Sie dies als root aus:

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

Das listet einen 32-stelligen Hexadezimalschlüssel auf. Die Ausgabe könnte beispielsweise sein:

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

Verwenden Sie dies, um Ihre .Xauthority-Datei zu generieren (als Benutzer, der sich erneut anmelden muss):

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

Ersetzen Sie 'c0eaf749aa252101a0f57d5087089db7' durch das, was vom Befehl list für Sie zurückgegeben wurde. Jetzt sollte Ihre .Xauthority 51 Byte groß sein und Sie können (wieder) eine Verbindung zum X-Server herstellen.

Versuchen Sie so etwas

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

Quelle

Ps : die akzeptierte antwort hat bei mir nicht funktioniert

Ich hatte den Fehler "Kein Protokoll angegeben", als ich eine Instanz von Selenium 3.3.1 über ein Startskript startete und dann den Chrome-Treiber in Selenium verwendete. Selenium wurde als derselbe Benutzer wie X11 ausgeführt und die Umgebungsvariable DISPLAY-Shell wurde korrekt festgelegt. Interessant ist, dass dieser Fehler nicht aufgetreten ist, als ich den Firefox-Treiber verwendet habe. Das Festlegen der XAUTHORITY-Shell-Umgebungsvariablen im Upstart-Skript, die auf den Wert von $ XAUTHORITY des aktiven X11-Benutzers verweisen, hat den Fehler für den Chrome-Treiber behoben.

Nebenbei bemerkt, der Fehler "Kein Protokoll angegeben" wurde vom Chrome / Chrome-Treiber gründlich vergraben und war keineswegs leicht zu finden. Ich bemerkte, dass Chrome weiterhin Verzeichnisse im Muster von erstellte /tmp/.org.chromium.Chromium.*, diese jedoch schnell verschwanden. Mir ist aufgefallen, dass sie eine Datei mit chrome_debug.logder Meldung "Kann Anzeige nicht öffnen" enthielten . Ich fand das ziemlich seltsam, da ich verifiziert habe, dass der Selenprozess das richtige DISPLAY enthält, /proc/$pid/environund die Ausgabe des Selenprozesses stracegründlicher untersuchte, was ergab, dass "kein Protokoll angegeben", was mich schließlich zu dieser Frage führte.

Dieser Fehler kann reproduziert werden, indem XAUTHORITY deaktiviert und versucht wird, einen X11-Client auszuführen. Beispielsweise:

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

Das war einfach. Das Problem tritt auf, wenn Sie in root sate sind und wollen das nutzen gksu einfach verlassen den Wurzelzustand und versuchen Sie es erneut

Geben Sie dies einfach in Ihr Terminal ein xhost +SI:localuser:root, export DISPLAY=:0.0und versuchen Sie es erneut

Anhand der Hinweise in den akzeptierten Antworten konnte ich das Problem anders lösen:

1. Suchen Sie die Xauth-Datei in dem Konto, das funktioniert (Xauth1)
2. Suchen Sie die Xauth-Datei in dem Konto, bei dem dies nicht der Fall ist (Xauth2).
3. Kopieren Sie Xauth1 nach Xauth2
4. Ändern Sie die Berechtigungen von Xauth2

In 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

Nehmen wir an, Sie versuchen, als Benutzer2 ( normaler Benutzer ) auf die Benutzeroberfläche zuzugreifen . Anschließend müssen Sie die Installationsoberfläche als Benutzer2 laden .

Versuchen Sie dies zu befolgen:

Melden Sie sich als root an :

sudo su

Testen Sie den x-Server:

xclock

Wenn Sie eine laufende Uhr sehen können, ist das eine gute Idee. Versuchen Sie nun Folgendes:

xhost

Das Ergebnis sollte so aussehen:

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

Lassen Sie jetzt user2 auf xhost zugreifen

xhost +SI:localuser:user2

Versuchen Sie nun erneut, sich bei Benutzer2 anzumelden und ein beliebiges GUI-Programm zu öffnen.