Viszonyom a Xorggal

Utaltam a Xorgot.

Aztan meglattam a Wayland fejlesztok hozzaallasat:
https://bugzilla.redhat.com/show_bug.cgi?id=1274451

Mostmar szeretem a Xorgot.

( TCH | 2021. 05. 07., p – 12:00 )

Aki nem akarja végigolvasni az összes kommentet, annak zanzásítva: Wayland alatt a 'sudo gui-app' parancs nem működik, nem fog elindulni a cucc, ugyanis a Freedesktop Team ismét megmenti a júzereket saját maguktól; ne akarjanak grafikus alkalmazásokat root jogosultságokkal futtatni, mert az elfogadhatatlan Linuxon és még nagyon veszélyes is, így hintsünk csókot a GUI-val felvértezett partícionálók, telepítők, konfigolók és bármilyen a rendszerfájlokhoz hozzáférést igénylő programok felé, vagy, "fixáljuk" meg egyesével magukat a programokat, úgy, hogy ne root-ként fussanak, hanem user-ként, de csináljanak privilege escalation-t a PolicyKit-tel, ami a "systemd sudo-ja". 5 évvel később: na jó, mégis belegányolunk egy hotfixet, de csak az X11 appokhoz, a Wayland-esek továbbra sem fognak menni.

Oldschool Computer - http://oscomp.hu

A gksu helyett már pkexec van, de a topicban csak egyszer hivatkoztak rá kb. öt éve, valami workaround kapcsán, de mindjárt írja is valaki, hogy az rpmconf-hoz nem jó.
Egyébként menetközben lehet látni a lezárt duplikációk miatt, hogy hányszor jelentették ugyanezt a bugot még másik hibajegy alatt; ha ennyi embernek előjött a probléma, még több év után is, akkor erre leginkább nincs megoldás; WONTFIX.

Oldschool Computer - http://oscomp.hu

A gksu/gksudo es a kdesu/kdesudo is csak specialis esetek osszeallasa eseten mukodik waylanden X-es alkalmazasok inditasa eseten. (Fedora + GNOME kombon mostmar ez a specialis osszeallas a default, de erre eveket kellett varni, es par hatarozottabb user kozbelepeset).

Valahogy igy. Kis csipegetes:

This is not a 'weakness' of Wayland, it's a weakness of gparted (and other graphical applications that try to run as root). gparted should not run its UI as root. It should run its UI as a regular user and use PolicyKit or something else similar to gain elevated privileges only when necessary to query or modify devices.

Many graphical applications have already been written along these lines. Doing it is not rocket science

[...]

There's no reason at all you can't write a graphical installer that works with policykit. This is, after all, precisely what GNOME Software is. It makes the software more secure, more flexible, and nicer for the user to use.

[...]

it's a perfectly well-understood situation. gparted needs to be rewritten for a Wayland world, there's really not much more to it than that.

[...]

This is not a 'weakness' of Wayland, it's a weakness of gparted (and other graphical applications that try to run as root). gparted should not run its UI as root. It should run its UI as a regular user and use PolicyKit or something else similar to gain elevated privileges only when necessary to query or modify devices.

Many graphical applications have already been written along these lines. Doing it is not rocket science

[...]

There's no reason at all you can't write a graphical installer that works with policykit. This is, after all, precisely what GNOME Software is. It makes the software more secure, more flexible, and nicer for the user to use.

[...]

it's a perfectly well-understood situation. gparted needs to be rewritten for a Wayland world, there's really not much more to it than that.

[...]

( uid_4263 v | 2021. 05. 07., p – 12:02 )

Szerkesztve: 2021. 05. 07., p – 12:02

Én meg leszarom. Egy ideig azt sem tudtam melyik fut, aztán kiderült hogy Wayland, mert nem tudtam chromium és electron alapú alkalmazásokból full screen share -t tolni pl. meetingeken. Áttértem Xorg -ra, megjavult. Ennyiből érdekelt a dolog.

( asch v | 2021. 05. 07., p – 12:12 )

Desktop gépen ezek a root fetisiszták teljesen hülyék! Gondold meg, minden adatod amit használsz, ami az érték a gépeden, amit meg akarnál védeni a támadóktól, az a usered accountja alatt van. Bármilyen kém-szolgáltatást is simán futtathatsz userként. Egy esetleges támadónak semmi szüksége nincsen root accountra!

Egy osztottan használt szerveren még van valami értelme a root védelmének, de ez is egyre ritkább, mert fillérekért lehet VPS-t venni, amin megint csak egy felhasználó lesz.

Mégis mi az ok amiért védeni kell a root accountot? Gondolom attól félünk, hogy root joggal be lehet állítani olyan scan rate-et is, amitől elpukkan a CRT monitorunk :-) Tönkreteszi a hekker a hadrvert!4!44!!! Jajj de félek tőle!

Ezektől az anti-feature-öktől én is rosszul vagyok. Ha szerintük annyira fontos ez, akkor legyen egy konfiguráció, aminek ez a default működése! Akinek meg nem tetszik, az kikapcsolja ezt a "védelmet" és kész.

Nekem az az irány tetszik amit a mobil OS-ek tolnak (ios, android) ilyen téren, sőt már a macOS nál is egyre inkább megy ez. Vagyis szofisztikáltan lehet különböző jogokat adogatni az appoknak, alapból meg a saját kis tárhelyükön kivül nem látnak semmit.

A rendszerközeli alkalmazásokat persze érdemes ettől külön kezelni valahogy.

Én azt próbálom magyarázni hogy a mobil os-eken a permission kezelés ki van kényszeritve, defaultból működik. Minden appot úgy teszel fel, és úgy használsz, hogy a hatálya alatt működik.

Egy csomó problémát megoldana a világban, ha a desktop rendszerek is ilyenek lennének. Pár évtized alatt sikerült rájönnie a nagy gyártóknak, hogy olyan rendszert kell az ember alá tenni, ami teljesen hülyének nézi és mindenben lekorlátozza, de közben megpróbálja jól használhatóvá tenni. És puff, ott az ios, meg az android, elég jól el is működgetnek.

 

Attól hogy a Linuxban ott van a chroot, az lxc, vagy a docker, vagy freebsd -n a jail, vagy solarisban (ha már halott rendszerekről is beszélgetünk) a zones, azzal még az emberek 99,5%-a sosem találkozik. Esetleg szakdolgozatot irnak róla, mint ahogy én, vagy a geekek, vagy az adminisztrátorok szórakoznak vele valahol a szerverszobában vagy a felhőben futó VM-eken.

És mit érnek vele, hogy ki van kényszerítve, amikor minden hónapban félmillió új malware jön ki pl. a droidra? Pedig hülyének nézi a júzert és mindenben lekorlátozza.

Egyébként desktop rendszerek is tudnak ilyenek lenni. Felteszel egy tetszőleges UNIX-ot és bekonfigurálod, hogy így menjen.

Az átlagember a droid/iOS féle rendszerrel sem találkozik, nem tudja, hogy under the hood hogyan zajlik a permissionkezelés, ennek megfelelően, ha aláteszel egy valamilyen jail ökoszisztémát desktop alatt, ugyanott vagy.

Oldschool Computer - http://oscomp.hu

Tudod milyenek a statisztikák, van itt egy darab szám kontextus nélkül, tehát pont azt jelenti amit valaki szeretne.

"Egyébként desktop rendszerek is tudnak ilyenek lenni. "

Tudnak lenni vs gyárilag ilyenek

"Az átlagember a droid/iOS féle rendszerrel sem találkozik, nem tudja, hogy under the hood hogyan zajlik a permissionkezelés, ennek megfelelően, ha aláteszel egy valamilyen jail ökoszisztémát desktop alatt, ugyanott vagy."

Igen.

Nem hiszem hogy nem értünk egyet, én csak azt mondom hogy az átlag desktop rendszer gyárilag konténerizált/permissionkezelt legyen, és ne az legyen a divat, hogy letöltöm a szetup ekszét a vadnyugatról és tolom rá a run as admint, mert a szomszéd józsikától eltanultam, hanem meg se tehessem, kivéve ha tényleg értek hozzá, mert évek munkájával kitanultam hogy hol kell kicselezni a rendszert. Egy ios rendszert rendesen szét kell verni azelőtt, hogy a hivatalos app store-on kivül bármit telepits rá, ott pedig nagyon durván auditált alkalmazások vannak. És ezek az alkalmazások úgy vannak összerakva, hogy elindul, és megkérdezi hogy mihez férhet hozzá, és ha nemet mondasz a mikrofonra, helymeghatározásra, kamerára, tárhelyre, anyám tyúkjára, akkor nem fér hozzá és kész.

Ebből is látszik hogy az iparnak megadatott a mobil os-ek kapcsán a lehetőség hogy újra kitalálja hogyan lehet használható és biztonságos rendszert adni az embereknek, és valahogy igy. A Windows esetén meg csigalassúsággal haladnak ezek a változások, mert ugye gondolni kell a sok-sok régi hülyeséghez hozzászokott emberre, aki biztos frászt kapna ha nem úgy futna a winampos kiguglizott setup exe ahogy mindig is 20+ éve.

Tudod milyenek a statisztikák, van itt egy darab szám kontextus nélkül, tehát pont azt jelenti amit valaki szeretne.

Kontextus nélküli szám? A kontextus az volt, hogy mobil OS-eken forced-per-app-jail van, mert az milyen biztonságos. És droidra mégis havi félmillió malware jön ki. Ergo hamis biztonságérzet.

Tudnak lenni vs gyárilag ilyenek

És ha gyárilag ilyenek? A biztonsági mérőszámot egy bekezdéssel feljebb találod. Kontextussal, nehogy szó érje a ház elejét.

én csak azt mondom hogy az átlag desktop rendszer gyárilag konténerizált/permissionkezelt legyen, és ne az legyen a divat, hogy letöltöm a szetup ekszét a vadnyugatról és tolom rá a run as admint, mert a szomszéd józsikától eltanultam, hanem meg se tehessem, kivéve ha tényleg értek hozzá, mert évek munkájával kitanultam hogy hol kell kicselezni a rendszert

Nesze nekünk demokratikus OS; tanulja csak meg a büdös júzer, hogy a rendszere nem az övé! Hanem a vendoré, a hackereké és a malware-eké. Mindenki más meg tudja kerülni a rendszert, csak ő nem. De legalább biztonságban érzi magát, hiszen legalább saját magától megvédtük, nem igaz? Csak mindenki mástól nem sikerült. Tiszta windóz ez a droid, én mondom.

Egy ios rendszert rendesen szét kell verni azelőtt, hogy a hivatalos app store-on kivül bármit telepits rá, ott pedig nagyon durván auditált alkalmazások vannak.

Ööö... Aha... Tényleg...
Olyan durván van auditálva, hogy csak az XcodeGhosttal 2500 féle app volt megfertőzve a store-ban és 128 millió júzer szopta be. Marginális kis hapci volt, na.

Ebből is látszik hogy az iparnak megadatott a mobil os-ek kapcsán a lehetőség hogy újra kitalálja hogyan lehet használható és biztonságos rendszert adni az embereknek, és valahogy igy.

Hát ha neked az biztonságos, hogy te csak "évek munkájával" tehetsz fel magadnak valami "nem hivatalos" cuccot, viszont a hivatalos repo-k meg tömve vannak malware-vel, a rendszerben meg több sérülékenység van, mint egy tisztességes windózban, akkor tudok neked egy eladó hidat. (Sőt, mindjárt kettőt is: egy északit, meg egy délit. Az alaplap nem szériatartozék.)

A Windows esetén meg csigalassúsággal haladnak ezek a változások, mert ugye gondolni kell a sok-sok régi hülyeséghez hozzászokott emberre, aki biztos frászt kapna ha nem úgy futna a winampos kiguglizott setup exe ahogy mindig is 20+ éve.

Nem is fut. Jön a SmartScreen, a Defender, a Security Essential és nem raksz fel te semmit. Ha vért pisálsz se. A saját frissen fordított Delphi programod sem fog futni. Rommákorlátoztuk a júzert, most már biztonságban van. Hopp, az update letörölte az egész gépet, hogy legyen hely a Candy Crush Saga-nak, a vírusra már nem is volt szükség, pedig a biztonság kedvéért az még pont feltelepült, mert az természetesen rendelkezett érvényes signature-rel. Sebaj, ha az update mindent letöröl, akkor a vírusnak is annyi; best antivirus 2021.

Oldschool Computer - http://oscomp.hu

systemd szerintem legjobb init rendszer ami letezik linuxra.
Ha leteznenek meg nagyon kicsi eszkozok, akkor lenne erteme ~20 soros ash scriptet berakni helyette..
openrc 2dik legjobb IMHO, a tobbi tobb problemat okoz mint amit megold.

Sok systemd-lofaszd -nek is van ertelme, de sajnos tenyleg megszaladt a szamuk, es sok olyan is van
ami megkerdojelezheto.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Én megmértem a szakdolgozatomhoz a disk kezelést docker alatt, csak egy "kicsit" lassabb. Annyival amennyit rohadtul nem veszel észre, kivéve ha nagyon durva workloadot tolsz rá és számit hogy 18 vagy 23 óra alatt végzel-e.

Más erőforrások kezelését nem mértem ki, de meglepődnék ha sokat rontana.

A walled garden (iOS) atlagusereknek kell. A powerusereknek es a deveknek viszont csak utjaban all a walled garden.

A macOS implementacioja raadasul a legtobb esetben megkerdezi a usert regen irt szoftverek eseten is, vagy ad mas workaroundra lehetoseget (persze ott is van kiveteles 15 eve irt szoftver, ahol ez nem mukodik, de az a ritkabb). A waylandnel ezt evekig meg se akartak probalni.

Édesmindegy. Az "ártatlan IT"-s is ugyanúgy beleszaladhat.

Egyik volt munkahelyemen egy volt kollégám szaladt bele még anno egy hasonló szituba, valószínűleg vagy egy flash vagy egy böngésző bugot kihasználva. Semmit nem kellett hozzá tenni, csak épp egy rossz oldalra tévedni.

Ja. Olyan jo, amikor senkit nem hagyunk dolgozni rendesen, es kapalozhat mindenki 3 tarsreszlegnel permissionokert, mert "0.001% esellyel egy senior IT-s is beleszaladhat". (Home office-ban ez vegkepp csodalatos elmeny)

Fejlesztoknek a walled garden csak utjaban all. Pont.

(Igen, tudom, sokszor bizonyos szerzodesek betartasa erdekeben nem lehetnek IT-soknak bizonyos privilegiumaik, de a gyakorlat egeszseges esetben ott is egy lepcsozetes folyamatot eredmenyez)

Fejlesztoknek a walled garden csak utjaban all. Pont.

Miben? Sem egy desktop app, sem egy microservice fejlesztése közben nem rézem azt, hogy annyira hátráltat, hogy nem vagyok admin a gépemen. Ha telepíteni kell valamit vagy valami rendszerbeállítást kell módosítani, akkor majd eleválom magam, egyébként meg mi a fasznak adjak még nagyobb támadási felületet?

Itt valami felreertes lesz. Defaultkent fejlesztoknek is minel kisebb privilegiumu userkent kene mindent hasznalnia. Es egy jo fejlesztonek ezt tudnia is kene. Termeszetesen en is ellenzem az adminkent futtatott Chrome-ot es tarsait. Ezt nem is tagadom. Windows XP admin usere ota azert sokat valtoztak a dolgok.

En olyanokat ertettem "walled garden utban all" alatt, hogy a fejlesztonek lehetosege sincs privilegiumot emelni. Idetartozik a jo oreg multis "a szabaly az szabaly", es ha 3 kulonbozo Java verzio telepitesehez root kell, akkor a fejleszto nyisson 6 ticketet es varjon, amig mindet felkapjak a megfelelo sorrendben, es magyarazza el tarsreszlegeknek, hogy ez eppen miert is nem alacsony prioritasu feladat, mert csak egy bizonyos Java verzion nem mukodik valamiert az a kurva rendszer.

Wayland tekinteteben pedig idetartozik az, hogy a wayland fejlesztoi 2016 es 2019 kozt ugy alltak hozza, hogy "majd a gparted meg a kde partitionmanager es a tobbi alkalmazas fejlesztoje majd szepen hozzajuk igazodik, es mind atirja, hogy polkitet hasznaljon az osszes ilyen alkalmazas, es azt is ugy, hogy csak backend kodon, tehat semmi olyanon, ami renderel is".

En ezt ertettem "walled garden" alatt. Amikor valaki mar azt is kitalalja, hogy szerinte a fejlesztonek is csak egyfelekeppen lenne szabad privilegiumot emelni. Es ezzel rengeteg esetet elfelejt lefedni, es abban sem rugalmas.

( kecske | 2021. 05. 07., p – 13:28 )

Viszonyom a Xorggal

A feleseged tud rola? :-)

Informatikus férj csak hajnalban ér haza. A neje vészjóslóan kérdezi:
- Hol voltál egész éjszaka?
- Képzeld drágám, az új titkárnőm munkaidő végén behozott nekem egy kávét, sejtelmesen rám mosolygott, majd az asztalra ülve szétnyílt a blúza. Nem bírtam visszafogni magam: és belecsókoltam a nyakába, erre ő teljesen megvadult, egymásnak estünk, elvesztettük a fejünket, végül egész éjjel szeretkeztünk.
- Hazudsz! Fogadjunk, hogy már megint azt a nyomorult Windows-t akartad felinstallálni a gépedre!

 

Ez a vicc jutott eszembe, csak Xorg-gal... :-D

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( BaT | 2021. 05. 07., p – 13:46 )

Unpopular opinion következik.

Nem olvastam az összes hozzászólást, de én abban nem látok kivetni valót, ha ezt a Wayland natív alkalmazások számára nem akarják megoldani. Van a problémára jobb megoldás, ezért új, vagy aktívan karbantartott alkalmazások számára nincs értelme egy elavult megoldást támogatni.

Viszont az XWayland egy kompatibilitasi réteg, ezért attól elvárható, hogy támogassa az X-en megszokott megoldásokat, még akkor is, ha azok a Wayland fejlesztők szerint elavultak.

Ezért én azzal nem értek egyet, hogy a natív Wayland és az XWayland azonos módon kell, hogy viselkedjen ebből a szempontból.

But xwayland access and wayland access should be as consistent as possible I think, so if we don't allow the wayland connection we shouldn't allow the xwayland connection either, imo.

Egyrészt ez a bug nem a protokollt érinti, hanem egy konkrét implementációt.

Másrészt más platformokon majd lesz a PolicyKit helyett más megoldás. A Wayland protokoll szempontjából ez teljesen irreleváns kérdés, a konkrét implementáció akár támogathatja a más account nevében futó alkalmazásokat.

A "bug" legalább két implementációt is érint (a Westont és a Muttert biztosan), ezen felül a Freedesktop fejlesztők azt mondták, hogy az alkalmazásokat kell "megfixálni", hogy a PolicyKit-tel menjenek; én erre utaltam, hogy hiába platformfüggetlen a protokoll, ha a szoftverek viszont kényszerből PolicyKit-függőek lesznek, mert a kompozitor megköveteli; a platformfüggetlen protokoll végül implementáció szinten platformfüggővé válik.

Micsoda, hol és mikor? Legjobb tudomásom szerint a PolicyKit-re nincs alternatíva. Van olyan implementáció, ami támogatja a PolicyKit nélküli privilege escalationt?

Oldschool Computer - http://oscomp.hu

Nem, a PolicyKit/polkit csak egy opció, amivel megoldható a probléma. Például GNOME alkalmazások esetén megoldás lehet az admin:// gvfs protokoll használata. Nyilván use-case függő, hogy milyen megoldást lehet alkalmazni, és biztos vannak olyan use-case-ek, amire jelenleg nincs kész megoldás. Épp ezért írom, hogy az ilyen alkalmazások számára legyen opció, hogy X alkalmazásként továbbra is működjön a rootként futtatás. Ezzel párhuzamosan pedig ki lehet fejleszteni azt a megoldást, amivel megoldható, hogy az alkalmazást ne kelljen rootként futtatni.

És ki fogja kifejleszteni azt a megoldást? Mert a Freedesktop közölte, hogy ott a PolicyKit, mindenki használja azt. És ha ki is fejleszti valaki, fogják azt támogatni a szoftverek? És egyébként akkor a végén hány konkurens "megoldás" lesz a problémára? Mindet támogatnia kellene a szoftvereknek, ha Wayland alatt privilege escalation-re van szükségük, mert az egyik platformon ez van, a másikon meg az? Ebből olyan Linux-onlyság/PolicyKit-onlyság lesz, mint a huszonegy.

Oldschool Computer - http://oscomp.hu

És ki fogja kifejleszteni azt a megoldást? Mert a Freedesktop közölte, hogy ott a PolicyKit, mindenki használja azt.

Gondolom az adott platform fejlesztői. Abban szerintem egyetértünk, hogy ez nem a Freedesktop feladata.

És ha ki is fejleszti valaki, fogják azt támogatni a szoftverek?

Ha szeretnék támogatni azokat a platformokat, akkor fogják. Ahogy a Windows/Linux/macOS triumvirátus platformfüggő megoldásait is támogatják a multiplatform szoftverek gond nélkül, nem látom miért okozna problémát a Linux/*BSD/*NIX platformfüggő megoldásainak támogatása.

És egyébként akkor a végén hány konkurens "megoldás" lesz a problémára?

Ha platformonként csak egy megoldás van, akkor nem egymás konkurensei. Ahogy pl. a Windows rendszerhívásai nem konkurensei a Linux rendszerhívásainak.

Mindet támogatnia kellene a szoftvereknek, ha Wayland alatt privilege escalation-re van szükségük, mert az egyik platformon ez van, a másikon meg az?

Ha az adott platformot támogatni szeretnék, akkor igen.

Ebből olyan Linux-onlyság/PolicyKit-onlyság lesz, mint a huszonegy.

Vagy meg lehet próbálni szabványosítani egy megoldást, csak akkor nem kell meglepődni, ha pl. megjelenik egy polkit-tel kompatibilis megoldás más platformokon.

Gondolom az adott platform fejlesztői. Abban szerintem egyetértünk, hogy ez nem a Freedesktop feladata.

Mi nem az ő feladatuk? Kifejleszteni a megoldást arra a problémára, amit ismételten ők maguk teremtettek? Ezen már túl vagyunk: Polkit-nek hívják. Ismét egy rossz válasz egy mesterségesen generált problémára.

Ha szeretnék támogatni azokat a platformokat, akkor fogják. Ahogy a Windows/Linux/macOS triumvirátus platformfüggő megoldásait is támogatják a multiplatform szoftverek gond nélkül, nem látom miért okozna problémát a Linux/*BSD/*NIX platformfüggő megoldásainak támogatása.

Melyik Linux? Melyik BSD? Melyik UNIX? Ezekből tengernyi van és számos különféle megoldást használnak a különféle dolgokra. (Ld. csomagkezelés, audio, I/O, stb.)

Ha platformonként csak egy megoldás van, akkor nem egymás konkurensei. Ahogy pl. a Windows rendszerhívásai nem konkurensei a Linux rendszerhívásainak.

A Polkit cross-platform megoldás. Szerinted, ha valaki lefejleszt egy alternatívát ami pl. FreeBSD-only, akkor vajon hányan fogják azt támogatni a Polkit helyett, ami több platformot támogat? Tehát, aki Polkit-alternatívát fejleszt, annak is cross-platform módon kell megcsinálnia. Ha pedig a Polkit-alternatívák cross-platformok lesznek, akkor konkurensek lesznek.

Ha az adott platformot támogatni szeretnék, akkor igen.

Aha és hányan fognak úgy dönteni, hogy ők bizony támogatni szeretnék a 0.0001%-os részesedéssel bíró platformokat? És hányan fogják azt mondani, hogy a mainstream Linux világgal lefedték a célfelhasználóik elsöprő többségét és le van tojva minden egyéb? És mindezt úgy, hogy van olyan megoldás, ami minden UNIX-like platformon működhetne és a Freedesktop pont ezt gáncsolta el, mert már megint rá akarják kényszeríteni a retardált ideológiáikat és szoftvereiket mindenkire.

Vagy meg lehet próbálni szabványosítani egy megoldást, csak akkor nem kell meglepődni, ha pl. megjelenik egy polkit-tel kompatibilis megoldás más platformokon.

Nem tudom feltűnt-e, de pontosan ez történik: Polkit-nek hívják; egyrészt a "problémát" jelen pillanatban csak rajta keresztül lehet "megoldani", mert nincs alternatívája, másrészt a legpopulárisabb UNIX-okon elérhető, ergo a Polkit a "szabvány" "megoldás" erre a "problémára".
Az meg, hogy ez a szemétdomb ezer sebből vérzik (pl. JavaScript-tel kezeli a jogosultságokat (milyen jó is az, amikor a JS VM egy SIGSEGV kíséretében magával rántja az egész rendszer jogosultságkezelését, mert hardened (Grsecurity) kernelt használsz; stability & security, 2 in 1!), vagy egy symlink hiánya miatt bukod az egész rendszer jogosultságkezelést (WONTFIX), vagy, hogy tökig van nyomva race condition-ökkel és bypass bugokkal (had ne linkeljem őket egyesével)), az meg megint senkit nem fog érdekelni; ez a "szabvány", punktum.
És mindezt a biztonság jegyében, mert sudo-val futtatni egy GUI-s alkalmazást "elfogadhatatlan" (WTF?!) Linuxon (és a többivel mi van?) és veszélyes, tehát használjunk helyette egy JS-infected ementáli crashware-t. Ha ez a "megoldás", akkor inkább a "probléma"...

Oldschool Computer - http://oscomp.hu

Csak ahol van systemd, ott. Más UNIX-okon is megy, ahol egyáltalán nincs systemd.

Már hogy lenne megoldott? A Wayland egy platformfüggetlen protokoll, a Polkit viszont csak adott platformokat támogat.
Azonfelül ez így még mindig egy db. vendor lock-on, hogy a Wayland appokhoz PolicyKit kell, ha privilegizált műveletet akar végrehajtani, mert nincs más.
És ignoráltad azt is, hogy a Polkit a rengeteg agyhalott breakage miatt kevésbé biztonságos, mint ha lehetne a GUI-s cuccokat rootként futtatni, tehát semmi értelme. Mesterségesen generált problémára adott rossz megoldás.

Oldschool Computer - http://oscomp.hu

Polkit IMHO megy mindenen ahol van ertelme.

"Wayland appokhoz PolicyKit kell"
Mi tokert kotelezo hozza ?

A privilegizlat daemon, figyelhet unix domain socketen, hasznalhat dbus vagy sajat wire protocolt.

AFAIK dbus -ra is retehetsz dolgokat polkit nelkul,
a polkit azert "kell" hogy egyseges authZ megoldas legyen,
ne minden app sajat maga talaja ki, ill fejesze le , illetve az user-nek ne kelljen minden apphoz megtanulni valamit ..

Ha a dolog megoldhato, siman egy csoport tagsaggal akkor polkit
lehet tulzas, de ha ettol complexebb dolog kell, nem biztos hogy rosz.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Polkit IMHO megy mindenen ahol van ertelme.

#define van értelme
Ki dönti ezt el?

Mi tokert kotelezo hozza ?

Nem deklaráltan kötelező, csak kvázi-kötelező, mert nincs alternatívája.

A privilegizlat daemon, figyelhet unix domain socketen, hasznalhat dbus vagy sajat wire protocolt.

AFAIK dbus -ra is retehetsz dolgokat polkit nelkul,
a polkit azert "kell" hogy egyseges authZ megoldas legyen,
ne minden app sajat maga talaja ki, ill fejesze le , illetve az user-nek ne kelljen minden apphoz megtanulni valamit ..

Ha a dolog megoldhato, siman egy csoport tagsaggal akkor polkit
lehet tulzas, de ha ettol complexebb dolog kell, nem biztos hogy rosz.

Te itt valamit nagyon benéztél. Itt arról volt szó, hogy a létező mainstream Wayland kompozitorok nem engedik privilegizált felhasználóval futtatni a grafikus appokat. Szó nem volt privilegizált daemonokról.
Vagy úgy értetted, hogy te úgy oldanád meg a dolgot, hogy írnál egy privilegizált daemont és a GUI-s appod azzal kommunikálna? Remélem nem azt akartad mondani, hogy a GUI-s telepítők majd úgy fognak menni, hogy előbb a júzernek sudo-val el kell indítania a privilegizált daemont, aminek annyi lesz a szerepe, hogy pár fájlt bemásol az /usr alá, meg pár konfigfájlt létrehoz az /etc alatt.

Oldschool Computer - http://oscomp.hu

Miert te hol gondoltad polkit hasznalatat ha nem egy privilegizalt daemonal valo kommunikacional ?

Meg minidg ott van sudo/su, grafikus program hivhat setuid/setcap binarist, mint ahogy
wireshark teszi.

'sudo app ', meg minidg forkolhat egy gui processzt a user neveben IMHO.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Miert te hol gondoltad polkit hasznalatat ha nem egy privilegizalt daemonal valo kommunikacional ?

A polkit nem csak arra jó, hogy konvulens módon végezz IPC-t, hanem arra is, hogy parancsokat hajts végre privilegizált szinten.

Meg minidg ott van sudo/su, grafikus program hivhat setuid/setcap binarist, mint ahogy
wireshark teszi.

'sudo app ', meg minidg forkolhat egy gui processzt a user neveben IMHO.

Pont arről van szó, hogy a sudo és su, meg a többi UID-trükk nem működik, mert a Wayland kompozitorok meggátolják, hogy más user nevében futtasd.

Oldschool Computer - http://oscomp.hu

Tetszoleges gui app hivhat tetszoleges alkalmazast.
Most gparted -rol volt szo, gparted hivhat nem gui alkalmazast (execve(2)) ami valahogy megoldja hogy legyen priv,
amit wayland nem akadalyozhat (akadalyoz) meg.

BTW, lasd lentebb, nekem latszolag mukodnek weston appok sudo -E -vel.
A problema tenyleg letezik meg ?

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Nem csak gparted-ről volt szó, hanem bármilyen programról, aminek root user kell. Ez a felesleges bonyolítás az, ami rossz válasz egy mesterségesen létrehozott problémára.

Írd be neki, hogy 'echo $USER', 'echo $UID', meg azt, hogy 'echo "valami" > /etc/kecske'. Ha azt írja ki, hogy root, meg 0, az /etc-be való írkálás meg működik, akkor gratulálok, fogtál egy bugot, mert a Freedesktop developerek szerint szándékos, hogy Wayland app nem futhat rootként, tehát ez egy hiba, szerintük.

Oldschool Computer - http://oscomp.hu

( zolti v | 2021. 05. 07., p – 15:55 )

Ezt használtam wayland alatt: 

xhost +si:localuser:root && pkexec gui-app && xhost -si:localuser:root

A KDE alatt gyorsan át lehet írni a parancsot az alkalmazásra kattintva.  

Szerintem szep lassan a kdesu/kdesudo is leimplementalja majd(?) ezt, amennyire lehet, es azon belul is egy lehetosegekhez kepest secure modon.

Ott inkabb a lemaradas merteke furcsa. Bar nem ez a legnagyobb KDE+wayland bug, a pixelszamolgatas sem erossege ennek a parosnak tavolsagok eseten. :)

( turul16 v | 2021. 05. 11., k – 11:37 )

# waypipe ssh -t localhost sudo -E weston-terminal

terminal megy rootkent.

nem tudom mit csianolok roszul de nekem ez is megy:
sudo -E weston-terminal

fedora33 .

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

weston-terminal el sem indul azon a gepen amin csak X11 -van.
X -nel meg auth van, mint mindenutt.

Van meg olyon kombo ahol nem tudok `sudo gui-app` ot csinalni ?

sway-t meg lehet kiprobalom kesobb.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.