Ve zprávičce to je krátce vysvětleno. Moderní desktopová aplikace si má navýšení práva v případě potřeby vyžádat přes PolicyKit (viz deset let starý článek na LWN) a ne být celá puštěná pod rootem. Zrovna GParted to řeší tak, že volá pkexec a nechá se spustit celý pod rootem. Je to nejjednodušší řešení, ale ne nejbezpečnější.
Obecně se doporučuje mít pod rootem spuštěno co nejméně kódu, protože to je poměrně velké bezpečnostní riziko. Proto třeba i démoni často po startu udělají nutné minimum (nabindují se na nízký port) a pak práva roota zahodí a běží pod běžným neprivilegovaným uživatelem. Poblázněný nebo útočníkem ovlivněný program pak nemá moc ovládnout či zlikvidovat celý systém.
Takže v bashi jednoduše požádám polkit, aby následující příkaz spustil pod rootem a ten se sám rozhodne, jakým způsobem si ty credentials vyzjistí?
Takhle se to přece dělalo v bashi - když běžela Xka, použil se gksu(do), jinak su(do) a heslo se zadalo v terminálu nebo v okně gksu.
Ano, každý desktop má svého autorizačního klienta pro Polkit, který výzvu pro zadání hesla zobrazí a výsledek předá zpět Polkitu. Může si ale člověk třeba definovat pravidlo, že určitý uživatel/skupina dostane práva ke konkrétní operaci automaticky bez zadávání hesla. Pěkné ukázky mají třeba na wiki Archu: https://wiki.archlinux.org/index.php/Polkit
Je tam i návod, jak spouštět pomocí Polkitu GParted.
>> dustin: Grafický dotaz na heslo v gksu/gksudo se používá často v jednoduchých skriptech, které je potřeba spouštět v GUI prostředí. Jak se tohle pak bude řešit?
yad --title "Heslo?" --entry --hide-text | sudo -S program
pokud YAD neznas, jde o forknute/vylepsene Zenity a kazdy kdo pise script pro pouziti v/s GUI by to znat mel ;-)
Špatná odpověď, kdesu čeká úplně stejný osud, taky byl odstraněn z unstable a testingu a dokonce o dost dřív.
Lol "Ja o koze, ty o voze."
https://tracker.debian.org/pkg/kdesu
[2018-03-29] kdesu 5.44.0-1 MIGRATED to testing (Debian testing watch)
[2018-03-21] Accepted kdesu 5.44.0-1 (source) into unstable (Maximiliano Curia)
[2018-02-26] Accepted kdesu 5.43.0-1 (source) into experimental (Maximiliano Curia)
Mě by zajímalo, jak je to vymyšlené. Protože s příchodem Waylandu přestala fungovat většina návodů na internetu, které používaly něco jako sudo gedit ...
. Na nefunkční sudo gparted
jsem už taky tvrdě narazail a musel oprašovat ovládání nějakého konzolového nástroje. Používal jsem i aplikaci, která čas od času potřebovala přistoupit k sériovému portu, což jsem řešil jednorázovým spuštěním přes sudo
a to už taky nejde. Takže jak na to?
Co je to PolicyKit? Je to standardní součástí jádra? Nechce někdo napsat článek s nějakým superjednoduchým examplem GUI aplikace, která tohle řeší?
konretne gparted, pkud se podivas na "binarku" gparted:
cat `which gparted`
zjistis ze jde o script kterej si tohle sam resi pres pkexec (coz je obdoba sudo prave pro PolicyKit) a pousti si pak gpartedbin... tzn. ze gpared NEmas poustet "sudo gparted" ale proste jen "gparted" a po zadani hesla se pousti pod rootem...
pravidlo pro PolicyKit si pak nese gparted sebou v balicku:
/usr/share/polkit-1/actions/org.gnome.gparted.policy
vice infa: https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html
Nevím, jak v Debianu, ale ve Fedoře je k dispozici blivet-gui, což je takový modernější GParted (na rozdíl od něj umí pracovat třeba s LVM), a ten umí pracovat s Polkitem. Trochu netradičním způsobem, protože si nežádá oprávnění pro jednotlivé operace, ale na začátku pro celý proces, protože knihovna blivet byla původně napsaná pro instalátor a tak nějak předpokládá práva roota, ale funguje i bez gksu a na Waylandu.
v DEB based neni, sam vis ze jde o interni vytvor Fedoraka ;-)
vim ze kdyz s tim zacal, sem to zkousel v Ubuntu, tusim bylo PPA, ted sem si rikal ze znovu zkusim, ale PPA neni, github repositare bez readme, resp. jen pro blivet-gui ale ne blivet... make install zavislej na rpm, atd, atd... :)
Pořád plánuju rozjet aspoň to PPA, ale času moc není. Taky by se toho mohl chytnout nějaký Debianista :-)
Závislosti na RPM jsem se snažil poctivě všude vyházet, i z Blivetu samotného. Měl bych to README pro blivet-gui trochu upravit, největší chybějící závislosti už v Debianu máme, takže ruční instalace už není tak hrozná (ale pořád ne tak jednoduchá). I testy mi na Debianu běží a nepadají :-)
Ja jsem pouzival cely linux jako root nekolik et, sudo jsem nepotreboval :-). Ovsem to bylo v dobe, kdy se 95% casu jelo v console a cas od casu se spustily X. Na internet se chodilo pres dial-up minicomem na textovou consoli providera. www stranky se prohlizely linxem a kdyz tam byl nejaky obrazek, stahl se napred k providerovi, pak zmodemem domu, spustily se X a v nich se programem xv zobrazil. Pak se vyskocilo z X a pokracovalo se v browsovani :-). To bylo v dobe, kdy prave prichazel kernel verze 1.0. Kdo si jeste vzpomene na gopher a ftp?
No v případě desktopových distribucí mi to nedává nějak smysl.
Věci co pro mě na desktopu mají největší cenu, jsou stejně přístupné pod normálním uživatelem. Pokud útočník nějakou skulinou povýší na roota a smaže mi třeba /etc nebo /usr/lib, tak se tomu jen zasměju, ale pokud mi pod uživatelem pomaže věci v /home/já, budu třeba smutný.
Existují dokonce distribuce, kde vše běží pod rootem. Já je nevyužívám spíše proto, že mi nevyhovují z jiných důvodů, ale neotravování zadáváním hesla bych jinak bral jako bonus.
Protiargumentem mohou být ale nějací speciální démoni, kteří běží pod svým vlastním hodně omezeným oživatelem (třeba cups pod cups?) a povýšení na roota (otázka je, jestli by se to zrovna takovým mohlo podařit skrze potenciálně děravé kdesu) by jim pomohlo zejména přepnout se na mě. Moc o tom ale nevím. Nějaké hinty?
Esteze to gksu nepouzivam:
Debian, balik policykit-1 zavisi na libpam-systemd (ktory ako vieme zavisi na systemd).
Tak teda dakujeme za ten "The Universal Operating System".
P.S.: Repozitar http://angband.pl/deb/archive.html ma policykit-1 skompilovany pre stretch bez zavislosti na systemd. Takze ono to ide aj univerzalne, ked sa naozaj chce...
Problém vidím v tom, že pokud userovi přestane něco fungovat (mají soudruzi z debianu skutečně vychytané všechny závislosti?), tak buď půjde do downgrade, nebo (poučen jinými) na vyšší verzi nepřejde. A pokud bude na něj činěn tlak, tak přejde jinam (viz rpm distribuce, který tento problém zřejmě vyřešen mají, jak ukazuje diskuse).
Druhou věcí je, že se zde soudruzi snaží vnutit jakýsi "bezpečnější", ale přitom výrazně složitější a chybovější systém, než je ten zavedený (už jen složitost obsluhy povede k produkci většího množství chyb). Jsem toho názoru, že přesně tohle je situace, která by u svobodného software neměla nastat.