Perché non riesco ad eseguire app GUI da 'root': “Nessun protocollo specificato”?

39

Ho installato debian sul mio computer ieri sera. Ora, non capisco perché non riesco a eseguire app GUI da un terminale quando eseguo come root.

Per esempio:

sudo -i
glxgears

Genera il seguente output:

No protocol specified
Error: couldn't open display :0

Ma quando apro il terminale per la prima volta posso eseguire glxgearsdall'account utente. È solo dopo aver fatto sudo -iche il problema si ripresenta. Questo accade per qualsiasi app GUI che provo a eseguire. Penso che sia probabilmente correlato a X11, ma non sono sicuro.

— Polpo
fonte

1

stackoverflow.com/a/20612084 questo ha funzionato perfettamente per me.

A proposito di Wayland, per ogni evenienza: Arch Wiki , "sudo con app grafiche non funziona su wayland" .

— Alexey,

39

L'accesso al server X richiede due cose:

La $DISPLAYvariabile che punta al display corretto (di solito :0)
Informazioni di autenticazione corrette

Le informazioni di autenticazione possono essere esplicitamente specificate tramite $XAUTHORITY, e per impostazione predefinita ~/.Xauthorityaltrimenti.

Se $DISPLAYe $XAUTHORITYè impostato per l'utente, sudoli imposterà anche per la nuova shell e tutto dovrebbe funzionare correttamente.

Se non sono impostati, probabilmente avranno valori errati per impostazione predefinita e non è possibile avviare e X applicazioni.

In Debian di $XAUTHORITYsolito non è impostato esplicitamente. Basta aggiungere

export XAUTHORITY=~/.Xauthority

al tuo .bashrco esplicitamente dire XAUTHORITY=~/.Xauthority sudo ...e tutto dovrebbe funzionare.

È inoltre possibile utilizzare xauth listper verificare se sono disponibili informazioni di autenticazione adeguate.

— Michas
fonte

1

xauth infomostra il percorso del file di autorità

— Tomas Tomecek

1

xhost +risolto il mio problema

— danger89,

3

Tieni presente che xhost +disattiva completamente l'autenticazione e consente a tutti di accedere a tutte le applicazioni sullo schermo ...

— michas

1

per debian, scrivo l'esportazione XAUTHORITY come root? perché non funziona su deb10? Accedo con sudo su

— marinara il

@marinara usa sudo -iinvece di sudo su -.

— michas,

24

Ho avuto la tua stessa domanda ma per un utente normale. Diciamo che voglio avviare Firefox usando l'account utente pippo. Ho effettuato l'accesso come barra:

[bar@localhost ~]$ sudo -u foo -H firefox

Purtroppo quel comando fallì con lo stesso errore della domanda (cioè nessun protocollo specificato e impossibile aprire il display)

La mia soluzione era semplicemente aggiungere l'utente foo all'elenco degli accessi autorizzati al server X.

xhost si:localuser:foo

Ed è stato così, sono stato quindi in grado di avviare Firefox (e altre applicazioni X) utilizzando sudoe l'utente foo.

Sfondo : su X Window, c'è un'architettura client / server. Quando si avvia un'applicazione, si richiede l'autorizzazione del server X per visualizzarla. Per impostazione predefinita, una volta aperta una sessione (accedi graficamente), tu (il tuo utente) è ovviamente permesso comunicare con il server e visualizzare le applicazioni. Altri utenti non dispongono di questa autorizzazione a meno che non sia stata specificata. xhostè uno strumento per manipolare l'elenco delle autorizzazioni. La siindica che la regola è lato server e autorizzare l'utente locale fooper applicazioni di visualizzazione. X Window è molto potente in questo senso e puoi visualizzare le applicazioni remote localmente giocando con la DISPLAYvariabile d'ambiente e xhost(ma non solo). Nei vecchi tempi, quando le persone scrivevanoxhost + e implicitamente ha permesso a tutti di usare la propria sessione X, era possibile visualizzare l'applicazione sullo schermo per scherzi ;-) non tanto al giorno d'oggi in quanto le persone usano sempre meno l'architettura client / server di X Window (almeno per quello che osservo nella ultimi 10 anni).

PS: l'ho fatto per lanciare Firefox in una sorta di "prigione" (per evitare una vulnerabilità come per pdf.js in futuro). Ma ho rapidamente scoperto che chiamare Firefox tramite sudo non gli consentirà di accedere all'audio né all'hardware video. Ma c'è un ragazzo che spiega chiaramente come attivare l'accelerazione dell'hardware video e l'audio quando si chiama Firefox tramite sudo . YMMV con queste istruzioni, ad esempio ho ancora un'autorizzazione negata con l'audio ma il video va bene (testato su Fedora 22 con SELinux ON).

— Huygens
fonte

1

Nel mio caso fooera root, cioè dovevo correre xhost si:localuser:rootsu Ubuntu 17.10.

— Karl Richter,

Dove aggiungi il xhost si:localhost<user>comando? Se nessun utente è connesso, nessuno ha un server X disponibile a cui concedere l'autorizzazione.

— cbcoutinho,

@cbcoutinho Il caso d'uso sopra riportato è quando qualcuno è connesso e vuole eseguire un'applicazione XWindow come qualcun altro sullo stesso host. Se spieghi il tuo caso d'uso (qual è il problema che vorresti risolvere), allora posso potenzialmente aiutarti.

— Huygens,

@Huygens Ho una workstation per la simulazione di fluidi che è anche dotata di una GPU. Rendo le visualizzazioni con ParaView, un programma integrato vtk, di solito sulla workstation stessa. ParaViewfornisce anche un modello di rendering client / server senza testa sicuro tramite ssh, che vorrei sfruttare a distanza invece di usare VNC. Senza accedere alla workstation ed eseguire xhost, non riesco a utilizzare la GPU. Ciò significa che non riesco a riavviare la macchina in remoto e ho ancora accesso alla GPU.

— cbcoutinho,

1

@cbcoutinho X Window è un'architettura server client. Quando ci si connette tramite ssh, la workstation locale diventa la finestra X del client. È possibile utilizzare xhost con protocolli non sicuri come rlogin ma non ssh. Devi istruire ssh a farlo per te. Utilizzare il flag -Xo (meglio?) -YSu ssh, farà il reindirizzamento corretto. Naturalmente è quindi necessario un server C locale. Tuttavia, con GPU e OpenGL, non sono sicuro di dove avvenga il rendering / calcolo, forse sul lato client, non su quello del server. Potrebbe essere difficile.

— Huygens,

10

Puoi farlo

Specificare il display da utilizzare sulla riga di comando, aggiungendo -display :0.0

o

Imposta la variabile d'ambiente nello script di login di root (uno di .bashrc, .profile, .bash_profile ...).

export DISPLAY=:0.0

Puoi verificare se è impostato,

$ env |grep DISPLAY
DISPLAY=:0.0

Per aprire il display per tutti gli utenti di tutti gli host come utente normale, puoi farlo con:

xhost +

— X Tian
fonte

1

xhost + funziona come misura temporanea prima di entrare come sudo

— Octopus

1

xhost +ha funzionato anche per me, solo che si sono dimenticati di menzionare che dovremmo eseguirlo dal terminale dell'utente che autorizza, non da un terminale sotto sudo su.

— Nyxee,

1

lavoro perfetto come un boom

— Adiii

3

Dato che sei su Debian, la soluzione semplice e supportata è quella di organizzare la sudocopia delle tue credenziali di autorizzazione X11. pam_xauthè incluso nel libpam-modulespacchetto esattamente per questo scopo; per usarlo, devi solo aggiungere

session  optional  pam_xauth.so

al tuo /etc/pam.d/sudofile. Puoi anche scegliere di aggiungerlo anche a su. Per informazioni complete, consultare la pam_xauthpagina man, ovviamente.

— Toby Speight
fonte

2

Cosa mi ha aiutato:

È possibile xauth generate :0 . trustedsul userlato, che genererà un nuovoMIT-MAGIC-COOKIE-1
Verifica che la chiave appena creata con xauth list' asla variabile andradice utente (they should be the same if yourxAuthority` stia puntando allo stesso file.
Voila, rootaccederà a qualsiasi X-Appdal terminale, ma solo temporaneamente.

Per renderlo permanente, vedi la risposta di @Huygens!

— Timo
fonte

1

Soluzione alternativa :

Servizi come cron in esecuzione in root non hanno accesso alla visualizzazione se l'utente x corrente non è root.

Dobbiamo solo aggiungere l'utente root a x, puoi farlo al momento del login con uno script di avvio

xhost local:root

A scopo di test possiamo semplicemente eseguire il comando sotto l'utente corrente e riavviare lo script root / job / service / ...

— intika
fonte

Solo curioso, perché dovresti eseguire un'app gui tramite un cron?

— Polpo,

nella mia distribuzione ho un lavoro cron cron (msec) che controlla lo stato della sicurezza del sistema e crea un rapporto ... quindi, invece di andare ai registri per controllare quel rapporto, preferisco avere una GUI popup con il rapporto quando quel lavoro viene eseguito

— intika,

Questo ha funzionato per me

— Marcus Vinicius Pompeu il

0

Il sudocomando ha un'opzione per preservare le variabili di ambiente.

 -E, --preserve-env            preserve user environment when running command

In modo che sia possibile eseguire il comando con l'opzione -E. Esempio:

sudo -E wireshark

Se non è necessario eseguire applicazioni critiche per la privacy come i browser Web, sarà meglio aggiungere l'opzione -E con sudo. Non è possibile eseguire Chrome o Firefox semplicemente aggiungendo l' opzione -E . Perché molti browser hanno implementato la protezione contro le violazioni dello spazio utente. La risposta di @ huygens potrebbe avere approfondimenti su questo argomento.

Nota: l' aggiunta dell'opzione -E non aiuta se l'ambiente dell'utente NON è presente DISPLAY e XAUTHORITY già impostato correttamente .

— shan
fonte

-1

usa questo comando e funzionerà

sudo cp /home/user/.Xauthority .Xauthority

— user187508
fonte

2

Questo darà cp: cannot stat ‘/home/user/.Xauthority’: No such file or directorysu una qualsiasi delle oltre 10 macchine basate su Debian a cui ho accesso.

— Anthon,

Questo dà un piccolo contesto (ad esempio, ti aspetti silenziosamente una directory corrente) e non menzioni effetti collaterali come problemi quando lo fai in più istanze X11. Penso che in questo modo sia un po 'confuso.

— v6ak,