Perché gksu / gksudo o l'avvio di un'applicazione grafica con sudo non funzionano con Wayland?


44

Ho installato Ubuntu 17.10. Ora ho problemi con gksu:

$ gksu -dg synaptic
No ask_pass set, using default!
xauth: /tmp/libgksu-HgUjgQ/.Xauthority
STARTUP_ID: gksu/synaptic/8760-0-alex-XPS-15-9530_TIME4974977
cmd[0]: /usr/bin/sudo
cmd[1]: -H
cmd[2]: -S
cmd[3]: -p
cmd[4]: GNOME_SUDO_PASS
cmd[5]: -u
cmd[6]: root
cmd[7]: --
cmd[8]: synaptic
buffer: -GNOME_SUDO_PASS-
brute force GNOME_SUDO_PASS ended...
Yeah, we're in...
Unable to init server: Could not connect: Connection refused
(synaptic:8767): Gtk-WARNING **: cannot open display: :1
xauth: /tmp/libgksu-HgUjgQ/.Xauthority
xauth_env: (null)
dir: /tmp/libgksu-HgUjgQ

Se non lo uso -g, la finestra di dialogo della password è disabilitata. Quindi sembra un problema con la creazione di un tty per root.

Qualche consiglio?


1
gksudonon funzionerà in una sessione Wayland , puoi passare a una sessione Xorg e provare.
pomsky,

2
L'errore stesso se un errore X "non riesce ad aprire display:: 1". Wayland è progettato in questo modo e, secondo l'opinione degli sviluppatori, non dovresti eseguire applicazioni grafiche come root dalla riga di comando. Puoi aggirare il problema con xhost.
Pantera

1
gksu -dg synaptic Non dovresti mai farlo comunque.
Rinzwind,

3
@ N0rbert smetti di aggiungere il 17.10 alle domande che menzionano il 17.10. I tag di versione devono essere utilizzati se la domanda è specifica per quella versione. La maggior parte di queste domande sono generalmente applicabili ovunque siano disponibili Wayland, GNOME Shell, ecc. E questo include versioni passate e future.
muru,

@maru. 16.04 LTS è attuale, 17.04 è vicino a EOL, quindi il normale 17.10 significa Wayland e GNOME Shell di default, quindi il tag 17.10 è utile, credo. È difficile trovare domande, in cui gli utenti hanno problemi con 17.10, ma non hanno risposte e commenti qui . Hanno bisogno di risposte, ma hanno dimenticato di aggiungere il tag 17.10 quando richiesto. Posso smettere di aggiungere tag. È stata una buona volontà.
N0rbert,

Risposte:


55

Nota che questa risposta è specifica per le versioni di Ubuntu che usano Wayland, la 17.10 è la prima versione che usa Wayland per impostazione predefinita.

È una caratteristica non un bug! È una caratteristica di progettazione di Wayland che non è possibile avviare applicazioni grafiche come root dal terminale.

Le discussioni principali sono ovviamente sui siti Fedora. Vedi il bug # 1274451 di Fedora e le applicazioni grafiche non possono essere eseguite come root in wayland (ad esempio gedit, beesu, gparted, nautilus) su Ask Fedora . Ma c'è anche qualche discussione sui siti di Ubuntu ( Ubuntu Devs Uncertain sull'uso di Wayland di default in 17.10 - OMG! Ubuntu ).

Segnalazione di bug di Ubuntu: impossibile avviare applicazioni pkexec sulla sessione di Wayland

Potenziale soluzione : se si stanno modificando i file di sistema con un editor grafico (come gedit), utilizzare uno strumento da riga di comando come nanoo vimo emacs. nanoè in genere più semplice per i nuovi utenti, vimè più potente e ha più funzioni, vedi questo tutorial di Vim o simili.

In ogni caso, se vuoi davvero o hai bisogno di eseguire applicazioni grafiche come root , imposta xhostprima quale forzatura di fallback su Xserver.

Per impostare le autorizzazioni eseguite:

xhost si:localuser:root 

Al termine, per rimuovere le autorizzazioni

xhost -si:localuser:root 

È possibile aggiungere un'opzione grafica / desktop per fare ciò secondo questo report di bug sinaptico

le applicazioni pkexec possono essere xhost +si:localuser:rootcurate inserendole nell'avvio automatico XDG come segue (idea di N0rbert):

cat <<EOF | sudo tee /etc/xdg/autostart/xhost.desktop
[Desktop Entry]
Name=xhost
Comment=Fix graphical root applications
Exec="xhost +si:localuser:root"
Terminal=false
Type=Application
EOF

Potresti aggiungere questo comando xhost a .bashrc, ma consiglierei un paio di alias

alias gsuon='xhost si:localuser:root'

alias gsuoff='xhost -si:localuser:root'

Puoi nominare gli alias come preferisci.

Per i dettagli vedere:


Torna a Xorg

Se preferisci Xorg per qualsiasi motivo, puoi selezionare di eseguire Xorg al login

Vedi Come passi da Wayland a Xorg in Ubuntu 17.10?


Questa soluzione funziona anche con Mir ?
Eliah Kagan,

Non conosco MIR, potrebbe.
Pantera

1
O semplicementexhost +local:
Chaskes

18
"È una caratteristica non un bug!" ... sospiro. Questo tipo di cose è esattamente la ragione per cui non riesco a convincere i miei amici e colleghi a passare a Linux. L'uso di VIM e Nano non è un'alternativa a GEdit. Gedit funziona come il blocco note, mentre devi imparare il codice CRTL per gli altri. E prendi ad esempio Nano usando termini come "Scrivi" invece di "Salva" .... Molto ostile per l'utente.
JHBonarius il

9
Anche questo rompe completamente gparted, che è un po 'importante per avere accesso. Che cosa è mai successo a "Non cercare di impedire alle persone stupide di fare cose stupide; riuscirai solo a impedire alle persone intelligenti di fare cose intelligenti."?
Matthew Najmon,

21

inserisci qui la descrizione dell'immagine soluzioni

In Wayland è spesso difficile eseguire programmi applicativi GUI con autorizzazioni elevate (sudo -H, gksu ...). È una buona idea svolgere tali compiti con gli strumenti da riga di comando.

Ma ci sono soluzioni alternative, se si dispone di uno strumento GUI, che funziona bene per te e richiede autorizzazioni elevate. (Uso due di questi strumenti standard: Synaptic Package Manager synaptice lo strumento di partizionamento Gparted gparted. Uso anche MakeUSB per creare unità di avvio USB mkusb, ma può eseguire le parti che richiedono autorizzazioni elevate senza grafica.)

xhost e sudo -H

  1. Esiste una soluzione alternativa per consentire ai programmi applicativi grafici di proprietà di utenti diversi da quelli che hanno effettuato l'accesso a Wayland,

    xhost +si:localuser:root
    
  2. gksue gksudonon sono in bundle con Ubuntu standard e non funzionano qui, ma funzionano in Xorg.

    Invece puoi usare

    sudo -H
    
  3. È una buona idea prevenire programmi applicativi grafici di proprietà di altri utenti dopo l'utente che ha effettuato l'accesso,

    xhost -si:localuser:root
    

gvfs admin backend

In Ubuntu 17.10 (gvfs> = 1.29.4) puoi usare il backend di amministrazione di gvfs. Si noti che è necessario il percorso completo,

gedit admin:///path/to/file

In teoria, il metodo di backend di amministrazione di gvfs (che usa polkit) è migliore e più sicuro (di xhoste xudo -H), indipendentemente dall'interfaccia utente che si utilizza.

Non eseguire l'intera applicazione come root. L'escalation dei privilegi avviene solo quando strettamente necessario. Vedi il seguente link e link da esso,

nautilus-admin

È anche possibile utilizzare nautilus-adminper operazioni sui file con autorizzazioni elevate e utilizzare geditcon autorizzazioni elevate. Questo è descritto nella seguente risposta AskUbuntu,

Accesso temporaneo per root al desktop Wayland tramite la funzione gks

Per favore, evita sudo GUI-program. Può far sì che il sistema sovrascriva i file di configurazione per il proprio ID utente normale con rootla configurazione e impostare la proprietà e le autorizzazioni per adattarsi roote bloccare il proprio ID utente normale. È necessario eseguire le applicazioni della GUI con sudo -Hcui vengono scritti i file di configurazione nella roothome directory di /root. Esempio:

sudo -H gedit myfile.txt

Ma c'è il rischio che tu dimentichi -H. Invece puoi creare una funzione, per esempiogks

gks () { xhost +si:localuser:root; sudo -H "$@"; xhost -si:localuser:root; }

e conservalo nel tuo ~/.bashrcvicino agli alias. Quindi puoi correre

gks gedit myfile.txt

in un modo simile a come hai usato gksudoprima.

analisi

È possibile verificare come sudo, sudo -He gksil lavoro con i seguenti comandi

sudodus@xenial32 ~ $ sudo bash -c "echo ~"
/home/sudodus
sudodus@xenial32 ~ $ sudo -H bash -c "echo ~"
/root
sudodus@xenial32 ~ $ gks () { xhost +si:localuser:root; sudo -H "$@"; xhost -si:localuser:root; }
sudodus@xenial32 ~ $ gks bash -c "echo ~"
localuser:root being added to access control list
/root
localuser:root being removed from access control list
sudodus@xenial32 ~ $ 

ed ovviamente

gks gedit myfile.txt

secondo l'esempio nella sezione precedente.

Metodo che funziona tramite il menu Alt-F2 e Gnome Shell

Invece di aggiungere una semplice funzione a una riga ~/.bashrc, puoi creare un sistema che funziona anche senza bash. Può essere comodo da usare, ma è più complicato da configurare. Si noti che è necessario installare solo una delle alternative, poiché la funzione di una riga disturberà l'utilizzo di questo sistema più complicato.

Tre file

Lo shellscript gks:

#!/bin/bash

xhost +si:localuser:root

if [ $# -eq 0 ]
then
  xterm -T "gks console - enter command and password" \
  -fa default -fs 14 -geometry 60x4 \
  -e bash -c 'echo "gks lets you run command lines with GUI programs
with temporary elevated permissions in Wayland."; \
read -p "Enter command: " cmd; \
cmdfile=$(mktemp); echo "$cmd" > "$cmdfile"; \
sudo -H bash "$cmdfile"; rm "$cmdfile"'
else
 xterm -T "gks console - enter password" -fa default -fs 14 -geometry 60x4 -e sudo -H "$@"
fi 

xhost -si:localuser:root;

Il file desktop gks.desktop:

[Desktop Entry]
Version=1.0
Categories=Application;System;
Type=Application
Name=gks
Description=Run program with temporary elevated permissions in Wayland
Comment=Run program with temporary elevated permissions in Wayland
Exec=gks %f
Icon=/usr/share/icons/gks.svg
Terminal=false
StartupNotify=false
GenericName[en_US.UTF-8]=Run program with temporary elevated permissions in Wayland

Il file icona gks.svgè simile al seguente:

inserisci qui la descrizione dell'immagine

Puoi scaricare il file icona o un tarball con tutti e tre i file da questo link,

wiki.ubuntu.com/Wayland/gks

Copia i file [estratti o copiati e incollati] nelle seguenti posizioni,

sudo cp gks /usr/bin
sudo cp gks.desktop /usr/share/applications/
sudo cp gks.svg /usr/share/icons

Esci / accedi o riavvia e dovrebbe esserci un'icona del desktop funzionante. Funzionerà da una finestra terminale come con la semplice soluzione con la funzione.

Alt F2 scatola:

inserisci qui la descrizione dell'immagine

Menu di Gnome Shell:

inserisci qui la descrizione dell'immagine

console gks e gparted:

inserisci qui la descrizione dell'immagine

Script personalizzato e file desktop

Se hai solo poche applicazioni GUI, che richiedono autorizzazioni elevate, puoi creare script personalizzati e file desktop per loro ed evitare di immettere il comando (nome dell'applicazione). Dovresti solo inserire la password, il che non è più difficile rispetto alle versioni precedenti di Ubuntu (dovresti comunque inserire la password).

Esempio con il semplice programma GUI xlogofornito con il pacchetto del programma x11-apps:

Lo shellscript gkslogo(semplificato rispetto a gks),

#!/bin/bash

xhost +si:localuser:root

xterm -T "gks console - enter password" -fa default -fs 14 -geometry 60x4 -e sudo -H xlogo

xhost -si:localuser:root;

Il file desktop gkslogo.desktop:

[Desktop Entry]
Version=1.0
Categories=Application;System;
Type=Application
Name=gkslogo
Description=Run program with temporary elevated permissions in Wayland
Comment=Run program with temporary elevated permissions in Wayland
Exec=gkslogo
Icon=/usr/share/icons/gks.svg
Terminal=false
StartupNotify=false
GenericName[en_US.UTF-8]=Run program with temporary elevated permissions in Wayland

Ero pigro e ho usato lo stesso file icona gks.svg

Copia i file [copiati e incollati] nelle seguenti posizioni,

sudo cp gkslogo /usr/bin
sudo cp gkslogo.desktop /usr/share/applications/

gks [logo] console e xlogo:

inserisci qui la descrizione dell'immagine


"L'accesso temporaneo per root al desktop Wayland tramite gks" è un metodo più sicuro (ad es. Di aggiungere un file come /etc/xdg/autostart/xhost.destopanche suggerito) perché termina ripristinando l'ambiente originale? E possiamo tranquillamente sostituire sudo -Hcon gksul'alias in modo da utilizzare l'inserimento nei file .desktop, ecc.?
Sadi,

1
Sì, penso che sia più sicuro consentire l'accesso root al desktop solo quando necessario. E sì, puoi sostituirlo sudo -Hcon gksunella funzione, potrebbe funzionare meglio per le tue applicazioni.
sudodus,

1
+1 per una risposta estremamente approfondita. Simile alla tua gksabbreviazione, avevo configurato gsul'uso dei kit di politiche (il nuovo futuro di 16.04) per gedite nautilus. Quando uscirà il 18.04 anche se penso che chiamerò semplicemente lo xhost +si...script wrapper gksuche non installerò mai dai pacchetti che iniziano 18.04.
WinEunuuchs2Unix

2
"Wayland è progettato per non consentire autorizzazioni elevate (sudo -H, gksu ...) con i programmi applicativi della GUI." - falso. Wayland consente le applicazioni di root bene. Puoi vederlo correndo sudo -E gedit. Esiste attualmente un bug in gdmcui configura il server di compatibilità Xwayland X11 per non supportare XAUTHORITY, necessario per il funzionamento delle applicazioni X11 in esecuzione come root. Le applicazioni native wayland eseguite come root funzionano bene.
psusi,

1
@psusi, ho modificato la risposta per evitare dichiarazioni sul design e le intenzioni di Wayland.
sudodus,

6

Meglio verificare se wayland è realmente in esecuzione prima di concedere il root a destra

if [ $XDG_SESSION_TYPE = "wayland" ]; then
    xhost +si:localuser:root
fi

5

Se si utilizza Ubuntu 17.04 o versioni successive, si consiglia di utilizzare il backend di amministrazione gvfs . Aggiungi semplicemente admin: // all'inizio del percorso file completo che desideri aprire in un'app come l' Editor di testo o le app File .

Ad esempio, per modificare le impostazioni di avvio, aprire

admin:///etc/default/grub

Questo metodo usa PolicyKit e continuerà a funzionare con le impostazioni predefinite Wayland di Ubuntu 17.10, mentre sudo e gksu per le app della GUI no.


1
Grazie. Per me questo ha funzionato meglio con gedit (tranne uno strano comportamento se usato semplicemente come gedit admin:), stranamente con nautilus (quasi inutile), e totalmente fallito con sinaptico . Qualche idea?
Sadi,

Non funzionerà con Synaptic. Dovrebbe funzionare bene in Nautilus, ma è necessario scegliere una directory non un file comeadmin:///etc/
Jeremy Bicha,

Funziona in qualche modo con nautilus ma vedrai cosa intendo ("molto stranamente", "quasi inutile") anche quando apri direttamente una directory e inizi a provare a fare questo e quello ;-)
Sadi

@Sadi Non ho idea di cosa sia "questo e quello". È possibile presentare un bug se non funziona correttamente.
Jeremy Bicha,

3

Per le applicazioni che usano su-to-root e pkexec potresti voler aggiungere questo codice a /etc/xdg/autostart(vedi il mio commento su launchpad ) a tuo rischio e pericolo:

cat <<EOF | sudo tee /etc/xdg/autostart/xhost.desktop
[Desktop Entry]
Name=xhost
Comment=Fix graphical root applications
Exec="xhost +si:localuser:root"
Terminal=false
Type=Application
EOF

Anche altre applicazioni root sono state interrotte su Wayland (vedi bug 1713313 e bug 1713311 ).


Se non desideri una soluzione permanente, puoi utilizzare il metodo di @ ravery:

basta digitare xhost +si:localuser:rootil terminale prima di avviare l'applicazione privilegiata


1

Se un'applicazione supporta l'API Wayland, puoi eseguirla come root usando il sudo -EH applicationcomando.

L'opzione -E dice a sudo di preservare le variabili di ambiente (così come WAYLAND_SOCKET e XDG_RUNTIME_DIR) necessarie per le applicazioni wayland. È sempre meglio usare questa opzione su un brutto hack xhost proposto in altre risposte. xhost consente l'esecuzione dell'applicazione da X wrapper, che è meno sicuro rispetto all'utilizzo di Wayland (appunti condivisi, keylogging ecc.). Il trucco sudo -EH non funzionerà con un'applicazione che non era stata riscritta per Wayland, come gparted per esempio, ma avrebbe funzionato con gedit ecc.


0

In realtà il seguente codice funziona quasi:

#! /bin/bash
set -e 
if [ -z "$1" ] ; then
    echo "Application is not specified" ;  exit
fi 
if [ $XDG_SESSION_TYPE = "wayland" ]; then
    if [[ -t 1 ]]; then
       xhost +si:localuser:root
       sudo -u root "$@"
       xhost  -  
       exit 0
    fi 
fi
gksu "$@"

(per favore, mi scusi per lo stile ingenuo di codifica bash - Sono una sorta di principiante con questo argomento). T non funziona in modo stabile da Alt-F2, se l'ultima selezione non era un terminale; in questo caso non possiamo semplicemente mettere a fuoco la finestra di dialogo della password Sembra che funzioni dal menu di Gnome. Comunque <1. Non è una soluzione al 100%. 2. Mi sembra che gli architetti di Ubuntu pensino che non dovremmo cercare alcuna soluzione.


1
Penso che tu voglia "$@"(invece di "$1" "$2" ...).
muru,

Sì, certo :-) Queste sono solo tracce dei miei esperimenti
Alex Chapiro,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.