Aplikacje KDE nie pozwolą na roota. Bezpieczeństwo ponad wolność
Jeszcze nie tak dawno na stronach KDE wiodącym hasłem było„Experience Freedom!” („doświadcz wolności”). I faktycznie,pod względem wolności dawanej swoim użytkownikom, to środowiskograficzne było bezkonkurencyjne. Było i jest – ale czy będziedalej? Hasło zniknęło, zastąpił je slogan o przyjaznymdoświadczeniu użytkownika, a w imię tej przyjazności zaczynająbyć podejmowane przez deweloperów KDE decyzje, które jakby temudoświadczeniu wolności przeczą.
Użytkownicy OpenSUSE, dystrybucji od zawsze świetniedopracowanej pod kątem implementacji KDE, skarżąsię na niemożliwość uruchomienia menedżera plików Dolphin zuprawnieniami roota. Problem dotyczy jednak nie tylko OpenSUSE, tosamo dzieje się we wszystkich dystrybucjach, w których pojawiłasię najnowsza wersja pakietu KDE Applications 17.04.0. Menedżerplików otrzymał w niej kilkaulepszeń (na czele ze zrobieniem porządku z menu kontekstowympanelu Miejsca), ale stał się bezużyteczny dla wszystkich tych,którzy chcieli go wykorzystać do wprowadzenia zmian w plikachsystemowych.
Wprowadzona łatka po prostu sprawdza, czy aplikacja jesturuchamiana z uprawnieniami roota, a jeśli tak, to jej uruchomieniezostaje przerwane, z komunikatem *Executing Dolphin as root is notpossible *(uruchomienie Dolphinajako root jest niemożliwe). Nie ma znaczenia, czy uruchomimymenedżer plików przez sudo, kdesu, dbus-launch czy z graficznegośrodowiska roota. Sprawa jest o tyle niepoważna, że Dolphin jestdomyślnym menedżerem plików KDE, więc w tym momencie na „czystym”systemie administrator po uruchomieniu graficznej sesji w ogóle niema dostępu do podstawowego menedżera plików.
Problem dotyczy nie tylkoDolphina, także inne aplikacje KDE przestały działać zuprawnieniami roota – włącznie z edytorem tekstu kwrite/kate.Martin Gräßlin, który od dawna był zwolennikiem takiej blokady,tłumaczy,że to wszystko dla bezpieczeństwa użytkowników, dostęp do plikówz uprawnieniami roota w graficznych aplikacjach korzystających zlicznych bibliotek (Qt, ale też Xlib, xcb, OpenGL itd.) jestekstremalnie niebezpieczny. Faktycznie, każde okno aplikacji X11 mapełno właściwości, do których może pisać każdy proces – niema tu żadnych mechanizmów kontroli dostępu i zaufania.
Sęk jednak w tym, żerozwiązanie proponowane przez Gräßlina, tj. używanie narzędziasudoedit, które wywołuje edytor (domyślnie vi), w tleprzeprowadzając operację na pliku tymczasowym, którym późniejnadpisywany jest później oryginał. Nie jest to jednak póki co aniwygodne, ani dobrze zintegrowane z powłoką graficzną. DeweloperKDE zapewnia jednak, że jest to lepsze, gdyż pozwala uruchomićedytor z własnym stylem graficznym, działa z Waylandem – ioczywiście jest bezpieczne.
Może i jest bezpieczne, alebezpieczeństwo to zapewniono w dość ordynarny sposób, znaczącoutrudniając użytkownikom operacje na plikach systemowych(szczególnie gdy jako domyślny edytor ustawiony jest vi, któregowielu linuksowych nowicjuszy po prostu nie umie). Właściwerozwiązanie powinno korzystać z systemowego mechanizmu zarządzaniaprawami użytkownika, tj. PolicyKit, w połączeniu np. z wirtualnymsystemem plików KIO. To pozwoliłoby zachować dotychczasoweprzyzwyczajenia, nie ograniczając wolności użytkownika – i nieczynić bezużytecznymi te wszystkie poradniki dla początkujących,w których unikano konsoli, polecając uruchomienie narzędzigraficznych z uprawnieniami roota.
