Linux: jak graficznie edytować plik tekstowy jako root?

Kategoria: Oprogramowanie Data publikacji: 2 komentarze

Pomimo, że w niektórych przypadkach pingwin ustępuje na tym polu wiodącym systemom operacyjnym, lubię korzystać z Linuksa w sposób graficzny. Edycja plików tekstowych (na przykład konfiguracji) w graficznym edytorze jest bezproblemowa. No, chyba że trzeba akurat zmodyfikować plik systemowy, tj. należący do użytkownika root. Da się to zrobić łatwo i szybko, ale należy zrobić to poprawnie, aby przy okazji nie przysporzyć sobie kłopotów.

Podejrzewam, że wśród web deweloperów jednym w najchętniej edytowanych plików systemowych jest plik /etc/hosts, dlatego tym przykładem posłużę się w moim poradniku. :-)

sudo gedit /etc/hosts — nie rób tego!

Zanim opiszę, jak należy edytować plik tekstowy jako root, pozwolę sobie wspomnieć, jak nie należy tego robić. Przeciętny użytkownik Linuksa ma świadomość, że uruchomienie w terminalu danego polecenia poprzez sudo, uruchamia je jako root — toteż edycja potrzebnego pliku przy użyciu ulubionego (lub po prostu preinstalowanego) edytora w ten sposób wydaje się najprostszą drogą. To jest zła droga, nie rób tak!

Nigdy nie należy uruchamiać graficznych aplikacji jako root (na przykład przez sudo). Nigdy!

Polecenia takie jak sudo gedit nazwa-pliku, sudo xed nazwa-pliku, sudo kwrite nazwa-pliku, sudo kate nazwa-pliku, sudo vscode nazwa-pliku albo sudo subl nazwa-pliku nigdy nie powinny być używane! Uruchamianie graficznej aplikacji jako root (np. za pomocą sudo) naraża twój system operacyjny nie tylko na zmniejszenie bezpieczeństwa, ale także na uszkodzenie plików konfiguracyjnych w twoim katalogu domowym, co może poskutkować na przykład niemożnością zalogowania się.

Istnieje sporo użytecznych aplikacji, które swój interfejs graficzny uruchamiają jako root: menadżer pakietów Synaptic, edytor partycji GParted czy narzędzie GSmartControl. Nie oznacza to jednak, że taki sposób działania jest prawidłowy, wręcz przeciwnie. Oznacza to jedynie, że tego typu aplikacje są źle zaprojektowane (w przestarzały i niebezpieczny sposób) i należy je poprawić!

Poza tym w nowoczesnych dystrybucjach Linuksa korzystających ze współczesnego serwera grafiki Wayland, takich jak Debian 10, Red Hat Enterprise Linux 8 czy Fedora, metoda uruchamiania graficznych aplikacji przez sudo może nawet (domyślnie) w ogóle nie zadziałać. Architektura serwera grafiki Wayland intencjonalnie nie pozwala na uruchamianie okna graficznego jako użytkownik inny niż bieżący.

Zatem jak wygodne i jednocześnie bezpiecznie edytować plik tekstowy jako root?

Sposób nr 1: sudoedit i wybór edytora

Program sudo posiada przełącznik --edit, który zmienia jego zachowanie w taki sposób, że jako argument zamiast polecenia do uruchomienia przyjmuje nazwę pliku. Istnieje również oddzielnie, bardzo wygodne polecenie sudoedit, które jest po prostu aliasem dla sudo --edit.

sudoedit /etc/hosts

Program sudoedit tworzy kopię wskazanego pliku, a następnie otwiera ją w domyślnym edytorze tekstowym. Po zakończeniu edycji, program sudoedit podmienia oryginalny plik na ten zmodyfikowany przez nas. Jedynie proces tworzenia kopii oraz podmiany plików następuje jako root, edytor tekstowy jest otwierany z poziomu naszego własnego konta użytkownika.

Domyślny edytor tekstowy możemy skonfigurować za pomocą zmiennej środowiskowej EDITOR. Jest ona używana nie tylko przez sudoedit, ale także przez wiele innych programów, na przykład git, dlatego warto dopasować ją do swoich potrzeb. Większość dystrybucji Linuksa prawdopodobnie jako domyślnego edytora używa tekstowego programu vi, jednak nic nie stoi na przeszkodzie, aby w jego miejsce ustawić inny edytor tekstowy — graficzny.

O ile do pracy z kodem używam obecnie Sublime Text VSCodium, o tyle do zadań czysto administracyjnych korzystam najczęściej z edytora systemowego. Większość istotnych dystrybucji Linuksa korzysta domyślnie ze środowiska GNOME, a to zaś dostarcza edytor gedit. To właśnie jego preferuję używać do takich zadań.

W całej tej prostocie sudoedit jest jednak pewien trudny do wyłapania na początku haczyk. Większość aplikacji graficznych działa na zasadzie jednej instancji, gedit nie jest tu wyjątkiem. Oznacza to, że gdy spróbujemy uruchomić polecenie gedit w terminalu, podczas gdy mamy już otwarte inne okno tego programu, uruchomione polecenie gedit jedynie przekaże pracę do wykonania już działającej instancji programu, a ono samo zakończy pracę. Takie zachowanie nie jest kompatybilne z poleceniem sudoedit, które „śledzi” wystartowaną przez siebie instancję edytora. Gdy ta instancja zakończy pracę, sudoedit od razu dokonuje podmiany pliku.

export EDITOR="gedit --wait --new-window"

Aby skonfigurować domyślny edytor, należy ustawić zmienną EDITOR na przykład w pliku ~/.profile. Powyżej zamieszczam przykład właśnie dla gedit. Jeśli chcesz użyć innego edytora, koniecznie zapoznaj się z jego dokumentacją i dowiedź się, jakich przełączników użyć, aby wystartować go w sposób kompatybilny z sudoedit, tj. w odseparowanym procesie.

Po skonfigurowaniu zmiennej EDITOR program sudoedit jest gotowy do pracy. Ma on jednak jedną drobną wadę: ze względu na jego sposób działania, wskazany plik nie jest modyfikowany w momencie wciśnięcia skrótu Ctrl+S w edytorze, lecz dopiero po zamknięciu okna edytora. Zazwyczaj nie jest to dużym kłopotem, ale w specyficznych przypadkach ta ułomność kompletnie dyskwalifikuje tę metodę!

Aktualizacja 2023: od GNOME 42 domyślnym edytorem plików tekstowych w miejsce gedit jest gnome-text-editor. Poniżej zamieszczam analogiczną wartość zmiennej EDITORprzeznaczonej do integracji z nowym edytorem GNOME.

export EDITOR="gnome-text-editor --standalone"

Sposób nr 2: protokół admin:// usługi GVFS

Usługa GVFS środowiska GNOME jest używana przez menadżer plików tego środowiska, jak również przez menadżery plików innych środowisk opartych na technologiach GNOME takich jak MATE, Cinnamon, XFCE czy Pantheon (Elementary OS). Dostarcza ona kilku użytecznych wirtualnych protokołów takich jak ssh://, ftps://, trash:// czy na przykład admin://.

Protokół admin:// pozwala na edycję dowolnego pliku (nie tylko tekstowego) jako root. Dzięki temu mechanizmowi aplikacja nadal jest uruchomiona z poziomu konta bieżącego użytkownika, jedynie należyta usługa GNOME uruchamia się jako root, aby obsługiwać odczyt i zapis plików.

Wymagane jest użycie aplikacji korzystającej pod spodem z technologii GNOME, tj. z GIO i GVFS, takich jak gedit, Nautilus, GIMP. Programy korzystające z innych interfejsów programistycznych do odczytu plików z dysku nie są kompatybilne z protokołem admin://.

Mechanizmu admin:// można używać na kilka sposobów, na przykład w terminalu poprzez:

gedit admin:///etc/hosts

Zauważ proszę brak sudo na początku. :) Zwróć też uwagę na trzy ukośniki: dwa z nich ozna­czają protokół, a ostatni to już element ścieżki. Te dwa pierwsze w adresach URL tego typu są opcjonalne (ciekawostka: również w przeglądarkach WWW), jednak warto je tam umieścić, bo niektóre składniki GNOME z jakiegoś powodu ich potrzebują (można poeksperymentować).

Zamiast polecenia gedit możesz spróbować użyć innego kompatybilnego edytora takiego jak pluma w środowisku MATE lub xed w środowisku Cinnamon.

Jest też inny sposób. W menadżerze plików GNOME możesz przejść do pożądanego folderu, a następnie wcisnąć skrót Ctrl+L, dopisać admin:// na początku ścieżki i zatwierdzić — w ten sposób Nautilus otworzy folder jako root. Kliknięcie któregokolwiek z plików również otworzy go za pośrednictwem mechanizmu admin://. Tutaj ujawnia się też drobna wada całej tej metody: za każdym razem środowisko graficzne pyta użytkownika o hasło, oddzielnie dla każdej aplikacji.

Dostęp do listingu plików jako root można uzyskać również z poziomu okna wyboru pliku GTK. W aplikacjach GNOME, takich jak gedit, w oknach otwierania i zapisywania pliku można wcisnąć skrót Ctrl+L, podobnie jak menadżerze plików, a następnie wpisać pełną ścieżkę do folderu, poprzedzając ją protokołem admin://, na przykład admin:///etc/. W tym wypadku może być konieczne umieszczenie ukośnika również na końcu ścieżki. Pliki wskazane z takiego listingu również zostaną otwarte od razu jako root.

Warty zaznaczenia jest fakt, że edycja plików za pośrednictwem protokołu admin:// nie jest obarczona ułomnością programu sudoedit: wciśnięcie skrótu Ctrl+S w oknie edytora natychmiast zapisuje zmiany na dysku.

Bonus: „otwórz jako root” w menu Nautilusa

Menadżer plików GNOME automatycznie korzysta z protokołu admin://, gdy użytkownik kliknie na folder, do którego nie ma uprawnień. Można jednak ułatwić sobie pracę, instalując do Nautilusa wtyczkę dostarczającą opcję „otwórz jako administrator” w menu kontekstowym wszystkich plików i folderów. Wtyczka nautilus-admin jest dostępna pod adresem: https://github.com/brunonova/nautilus-admin. Niestety autor porzucił jej rozwój, ale nadal działa bezproblemowo.

Wtyczkę możesz zainstalować, posługując się instrukcjami autora lub instalując paczkę dla twojej dystrybucji. Jeśli korzystasz z systemu Fedora, możesz zainstalować ją z mojego repozytorium COPR za pomocą poniższych poleceń:

sudo dnf copr enable tomaszgasior/mushrooms
sudo dnf install nautilus-admin
nautilus -q

Komentarze (2)

  1. stała czytelniczka

    Ty korzystasz z Fedory? Zastanawiam się, czy ktoś jeszcze używa Debiana…

  2. Tomasz Gąsior

    Systemy takie jak Debian i CentOS mają sens na serwerach. Dostarczają przestarzałe oprogramowanie. Dodatkowo Debian jeszcze bardziej skrajnie niż Fedora podchodzi do sterowników własnościowych — na moim laptopie na Debianie nawet nie mam wifi po instalacji, chyba że użyję specjalnej „nieoficjalnej” wersji instalatora z dogranymi sterownikami niewolnymi. Debian jest po prostu niepraktyczny. Ani nie dostarcza świeżego softu (Arch Linux i Fedora dostraczają), ani nie tworzy niczego (Ubuntu i Fedora tworzą), ani nie ma zaplecza komercyjnego (Ubuntu i Fedora mają), ani nie ułatwia instalacji wlasnościowego softu (Arch ułatwia).

Dodaj komentarz