Dlaczego gksu / gksudo lub uruchomienie aplikacji graficznej z sudo nie działa z Waylandem?

44

Zainstalowałem Ubuntu 17.10. Teraz mam problem z 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

Jeśli nie używam -g, okno dialogowe hasła jest wyłączone. Wygląda to na problem z tworzeniem tty dla roota.

Jakakolwiek rada?

Alex Chapiro
źródło
1
gksudonie będzie działać w sesji Wayland , możesz przełączyć się na sesję Xorg i spróbować.
pomsky
2
Sam błąd, jeśli błąd X „nie można otworzyć wyświetlacza:: 1”. Wayland jest zaprojektowany w ten sposób i, zdaniem programistów, nie powinieneś uruchamiać aplikacji graficznych jako root z wiersza poleceń. Możesz pracować z xhostem.
Panther
1
gksu -dg synaptic I tak nigdy nie powinieneś tego robić.
Rinzwind
3
@ N0rbert przestań dodawać 17.10 do pytań, które wspominają 17.10. Tagów wersji należy używać, jeśli pytanie dotyczy konkretnego wydania. Większość z tych pytań ma ogólne zastosowanie wszędzie tam, gdzie dostępne są Wayland, GNOME Shell itp., W tym także poprzednie i przyszłe wersje.
muru
@maru. 16.04 LTS jest aktualny, 17.04 jest blisko EOL, więc normalne 17.10 oznacza Wayland i domyślną powłokę GNOME, więc myślę, że tag 17.10 jest przydatny. Trudno jest znaleźć pytania, w których użytkownicy mają problemy z 17.10, ale nie mają tutaj odpowiedzi i komentarzy . Potrzebują odpowiedzi, ale na pytanie zapomniały dodać tag 17.10. Mogę przestać dodawać tag. To była dobra wola.
N0rbert

Odpowiedzi:

55

Uwaga: ta odpowiedź jest specyficzna dla wersji Ubuntu korzystających z Wayland, 17.10 jest pierwszą wersją domyślnie używającą Wayland.

To funkcja, a nie błąd! Jest to cecha konstrukcyjna Wayland, że nie można uruchamiać aplikacji graficznych jako root z terminala.

Główne dyskusje odbywają się oczywiście na stronach Fedory. Zobacz błąd Fedory nr 1274451, a aplikacje graficzne nie mogą być uruchamiane jako root w Wayland (np. Gedit, beesu, gparted, nautilus) na Ask Fedora . Ale jest też trochę dyskusji na stronach Ubuntu ( Ubuntu Devs niepewnie domyślnie używa Waylanda w wersji 17.10 - OMG! Ubuntu ).

Raport o błędzie Ubuntu: Nie można uruchomić aplikacji pkexeced w sesji Wayland

Potencjalne obejście - jeśli edytujesz pliki systemowe za pomocą edytora graficznego (takiego jak gedit), użyj narzędzia wiersza poleceń, takiego jak nanolub vimlub emacs. nanojest zazwyczaj łatwiejszy dla nowych użytkowników, vimjest bardziej wydajny i ma więcej funkcji, zobacz ten poradnik Vima lub podobny.

W każdym razie, jeśli naprawdę chcesz lub potrzebujesz uruchomić aplikacje graficzne jako root , ustaw xhostnajpierw, który wymusza powrót do Xserver.

Aby ustawić uprawnienia, uruchom:

xhost si:localuser:root 

Po zakończeniu usuń uprawnienia

xhost -si:localuser:root 

Możesz dodać opcję graficzną / pulpitu, aby to zrobić zgodnie z tym raportem o błędach synaptycznych

Aplikacje pkexeced można leczyć za pomocą xhost +si:localuser:rootumieszczonego w XDG autostartu w następujący sposób (pomysł N0rberta):

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

Możesz dodać to polecenie xhost do .bashrc, ale radziłbym parę aliasów

alias gsuon='xhost si:localuser:root'

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

Możesz nazywać aliasy, jak chcesz.

Aby uzyskać szczegółowe informacje, patrz:


Wróć z powrotem do Xorg

Jeśli wolisz Xorg z jakiegokolwiek powodu, możesz wybrać uruchamianie na Xorg podczas logowania

Zobacz Jak przełączyć się z Wayland z powrotem na Xorg w Ubuntu 17.10?

Pantera
źródło
Czy to obejście działa również z Mirem ?
Eliah Kagan
Może nie wiem o MIR.
Panther
1
Lub po prostuxhost +local:
chaskes
18
„To funkcja, a nie błąd!” ... westchnienie. Tego rodzaju rzeczy są właśnie powodem, dla którego nie mogę przekonać mojego przyjaciela i kolegów do przejścia na system Linux. Korzystanie z VIM i Nano nie jest alternatywą dla GEdit. Gedit działa jak notatnik, podczas gdy musisz nauczyć się kodu CRTL dla tych innych. Weźmy na przykład Nano, używając terminów takich jak „Napisz” zamiast „Zapisz” .... Bardzo nieprzyjazny dla użytkownika.
JHBonarius
9
To również całkowicie łamie gparted, co jest dość ważną rzeczą, aby mieć do niego dostęp. Co się stało z „Nie próbuj powstrzymywać głupich ludzi przed robieniem głupich rzeczy; uda ci się tylko uniemożliwić mądrym ludziom robienie mądrych rzeczy”.
Matthew Najmon
21

wprowadź opis zdjęcia tutaj Rozwiązania

W Wayland często trudno jest uruchamiać aplikacje GUI z podwyższonymi uprawnieniami (sudo -H, gksu ...). Dobrym pomysłem jest wykonywanie takich zadań za pomocą narzędzi wiersza poleceń.

Istnieją jednak obejścia, jeśli masz narzędzie GUI, które działa dobrze i wymaga podwyższonych uprawnień. (Używam dwóch takich standardowych narzędzi: Synaptic Package Manager synaptici narzędzia do partycjonowania Gparted,. gpartedUżywam MakeUSB również do tworzenia napędów rozruchowych USB mkusb, ale może on uruchamiać części, które wymagają podniesionych uprawnień bez grafiki.)

xhost i sudo -H

  1. Istnieje obejście umożliwiające graficzne programy aplikacyjne będące własnością innych użytkowników niż zalogowany użytkownik w Wayland,

    xhost +si:localuser:root
    
  2. gksui gksudonie są dołączone do standardowego Ubuntu i nie działają tutaj, ale działają w Xorg.

    Zamiast tego możesz użyć

    sudo -H
    
  3. Dobrym pomysłem jest zapobieganie graficznym programom aplikacyjnym, które są własnością innych użytkowników niż zalogowany użytkownik,

    xhost -si:localuser:root
    

backend administratora gvfs

W Ubuntu 17.10 (gvfs> = 1.29.4) możesz użyć backendu administracyjnego gvfs. Zauważ, że potrzebujesz pełnej ścieżki,

gedit admin:///path/to/file

Teoretycznie metoda administracyjna gvfs (która korzysta z polkit) jest lepsza i bezpieczniejsza (niż xhosti xudo -H), niezależnie od używanego interfejsu użytkownika.

Nie uruchamiasz całej aplikacji jako root. Eskalacja uprawnień ma miejsce tylko wtedy, gdy jest to absolutnie konieczne. Zobacz poniższy link i linki z niego,

nautilus-admin

Możliwe jest również użycie nautilus-admindo operacji na plikach z podwyższonymi uprawnieniami i użycie geditz podwyższonymi uprawnieniami. Jest to opisane w następującej odpowiedzi AskUbuntu,

Tymczasowy dostęp użytkownika root do pulpitu Wayland za pośrednictwem funkcji gks

Proszę unikać sudo GUI-program. Może to spowodować nadpisanie przez system plików konfiguracyjnych zwykłego identyfikatora użytkownika rootkonfiguracją oraz ustawienie własności i uprawnień w celu dopasowania rooti zablokowania zwykłego identyfikatora użytkownika. Powinieneś uruchomić aplikacje GUI sudo -H, które zapisują pliki konfiguracyjne w rootkatalogu domowym /root. Przykład:

sudo -H gedit myfile.txt

Ale istnieje ryzyko, że zapomnisz -H. Zamiast tego możesz na przykład utworzyć funkcjęgks

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

i przechowujcie go w ~/.bashrcpobliżu pseudonimów. Potem możesz biec

gks gedit myfile.txt

w podobny sposób jak gksudowcześniej.

Testowanie

Można sprawdzić, w jaki sposób sudo, sudo -Ha gkspracę z poniższych poleceń

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 ~ $ 

i oczywiście

gks gedit myfile.txt

zgodnie z przykładem w poprzedniej sekcji.

Metoda działająca poprzez Alt-F2 i menu Gnome Shell

Zamiast dodawać prostą funkcję jednowierszową ~/.bashrc, możesz stworzyć system, który działa również bez basha. Może być wygodny w użyciu, ale jego konfiguracja jest bardziej skomplikowana. Zauważ, że powinieneś zainstalować tylko jedną z alternatyw, ponieważ funkcja jednowierszowa zakłóci korzystanie z tego bardziej skomplikowanego systemu.

Trzy pliki

Skrypt 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;

Plik na pulpicie 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

Plik ikony gks.svgwygląda następująco:

wprowadź opis zdjęcia tutaj

Możesz pobrać plik ikony lub archiwum ze wszystkimi trzema plikami z tego linku,

wiki.ubuntu.com/Wayland/gks

Skopiuj [wyodrębnione lub skopiowane i wklejone] pliki do następujących lokalizacji,

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

Wyloguj się / zaloguj lub uruchom ponownie, a na pulpicie powinna znajdować się działająca ikona. Będzie działał z okna terminala, podobnie jak w przypadku prostego rozwiązania z funkcją.

Alt F2 pudełko:

wprowadź opis zdjęcia tutaj

Menu Gnome Shell:

wprowadź opis zdjęcia tutaj

Konsola gks i gparted:

wprowadź opis zdjęcia tutaj

Niestandardowy skrypt i plik na pulpicie

Jeśli masz tylko kilka aplikacji GUI, które wymagają podwyższonych uprawnień, możesz tworzyć dla nich niestandardowe skrypty i pliki pulpitu i unikać wpisywania polecenia (nazwy aplikacji). Podałbyś tylko hasło, co nie jest trudniejsze w porównaniu z poprzednimi wersjami Ubuntu (i tak powinieneś wpisać hasło).

Przykład z prostym programem GUI xlogodostarczanym z pakietem programu x11-apps:

Shellscript gkslogo(uproszczony w porównaniu do 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;

Plik na pulpicie 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

Byłem leniwy i użyłem tego samego pliku ikon gks.svg

Skopiuj pliki [skopiowane i wklejone] do następujących lokalizacji,

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

Konsola gks [logo] i xlogo:

wprowadź opis zdjęcia tutaj

sudodus
źródło
Czy „Tymczasowy dostęp użytkownika root do pulpitu Wayland za pośrednictwem funkcji gks” jest bezpieczniejszą metodą (np. Niż dodanie pliku, jak /etc/xdg/autostart/xhost.destopsugerowano również), ponieważ kończy się przywróceniem oryginalnego środowiska? I możemy bezpiecznie wymieniać sudo -Hsię gksuw alias tak aby użyć INSERT do .desktop plików, itp?
Sadi
1
Tak, uważam, że bezpieczniej jest zezwolić na dostęp roota do pulpitu tylko w razie potrzeby. I tak, można wymienić sudo -Hze gksuw funkcji, to może lepiej dla aplikacji.
sudodus
1
+1 za niezwykle dokładną odpowiedź. Podobnie jak w przypadku twojego gksskrótu, musiałem skonfigurować gsuzestawy polis (nowa przyszłość dla 16.04) dla gediti nautilus. Kiedy pojawi się 18.04, myślę, że po prostu xhost +si...nazwiemy skrypt otoki, gksuktórego nigdy nie instaluję z pakietów zaczynających się od 18.04.
WinEunuuchs2Unix
2
„Wayland został zaprojektowany tak, aby nie zezwalać na podwyższone uprawnienia (sudo -H, gksu ...) w aplikacjach GUI.” -- fałszywe. Wayland zezwala na aplikacje root. Możesz to zobaczyć, uruchamiając sudo -E gedit. Obecnie występuje błąd gdmpolegający na tym, że serwer zgodności Xwayland X11 nie obsługuje XAUTHORITY, co jest wymagane w przypadku aplikacji X11 działających jako root do działania. Natywne aplikacje Wayland działające jako root działają dobrze.
psusi
1
@psusi, zmodyfikowałem odpowiedź, aby uniknąć stwierdzeń na temat projektu i intencji Waylanda.
sudodus
6

Lepiej sprawdź, czy Wayland naprawdę działa jako pierwszy, zanim przyznasz rootowi prawo

if [ $XDG_SESSION_TYPE = "wayland" ]; then
    xhost +si:localuser:root
fi
Eli Chan
źródło
5

Jeśli używasz Ubuntu 17.04 lub nowszej wersji, zaleca się użycie backendu administracyjnego gvfs . Po prostu dodaj admin: // na początku pełnej ścieżki pliku, którą chcesz otworzyć w aplikacji takiej jak Edytor tekstu lub aplikacje Pliki .

Na przykład, aby zmienić ustawienia rozruchu, otwórz

admin:///etc/default/grub

Ta metoda używa PolicyKit i nadal będzie działać z domyślnym Waylandem Ubuntu 17.10, podczas gdy sudo i gksu dla aplikacji GUI nie.

Jeremy Bicha
źródło
1
Dzięki. Dla mnie to działało najlepiej z gedit (z wyjątkiem dziwnego zachowania, gdy jest po prostu używany jako gedit admin:), bardzo dziwnie z nautilusem (prawie bezużytecznym) i całkowicie nie powiodło się z synaptic . Jakieś pomysły?
Sadi
Nie będzie działać z synaptic. Powinno to jednak działać dobrze w Nautilusie, ale musisz wybrać katalog inny niż plikadmin:///etc/
Jeremy Bicha
To trochę działa z nautilus, ale zobaczysz, co mam na myśli („bardzo dziwnie”, „prawie bezużyteczne”), nawet gdy bezpośrednio otworzysz katalog i zaczniesz próbować to i tamto ;-)
Sadi
@Sadi Nie mam pojęcia, co to jest „to i tamto”. Możesz zgłosić błąd, jeśli nie działa poprawnie.
Jeremy Bicha
3

W przypadku aplikacji korzystających z su-to-root i pkexec możesz dodać ten kod do /etc/xdg/autostart(patrz mój komentarz na launchpad ) na własne ryzyko:

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

Inne aplikacje root również są uszkodzone w Wayland (patrz błąd 1713313 i błąd 1713311 ).


Jeśli nie chcesz stałego rozwiązania, możesz użyć metody @ ravery's:

po prostu wpisz xhost +si:localuser:rootterminal przed uruchomieniem uprzywilejowanej aplikacji

N0rbert
źródło
1

Jeśli aplikacja obsługuje Wayland API, możesz uruchomić ją jako root za pomocą sudo -EH applicationpolecenia.

Przełącznik -E mówi sudo, aby zachowało zmienne środowiskowe (a także WAYLAND_SOCKET i XDG_RUNTIME_DIR) potrzebne do aplikacji Wayland. Zawsze lepiej jest używać tej opcji w stosunku do paskudnego hacka xhost zaproponowanego w innych odpowiedziach. xhost pozwala aplikacji uruchamiać się z X-wrappera, co jest mniej bezpieczne niż korzystanie z Waylanda (wspólny schowek, keylogging itp.). Sztuczka sudo -EH nie będzie działać z aplikacją, która nie została przepisana dla Wayland, na przykład gparted, ale działałaby z gedit itp.

ZAB
źródło
0

Właściwie następujący kod prawie działa:

#! /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 "$@"

(przepraszam za naiwny styl kodowania bash - jestem rodzajem początkującym w tym temacie). T nie działa stabilnie z Alt-F2, jeśli ostatni wybór nie był terminalem; w tym przypadku po prostu nie możemy ustawić fokusu w oknie dialogowym hasła. Wygląda na to, że działa z menu Gnome. W każdym razie <1. To nie jest 100% rozwiązanie. 2. Wydaje mi się, że architekci Ubuntu uważają, że nie powinniśmy przeszukiwać żadnych miejsc pracy.

Alex Chapiro
źródło
1
Myślę, że chcesz "$@"(zamiast "$1" "$2" ...).
muru
Tak, oczywiście :-) To tylko ślady moich eksperymentów
Alex Chapiro,