Root jog nélkül futó X szervert eredményező változtatásokat javasolt az Intel egyik fejlesztője

X, Wayland, Mir

Az egyik előnye lehet annak, ha a különböző grafikus hardverek eszközmeghajtó-programjait rávesszük a Kernel ModeSetting (KMS), a kernelbeli GPU memóriakezelők (TTM vagy GEM) és egyéb X innovációk használatára, hogy előbb-utóbb lehetővé válhat az X szerver root privilégiumok nélküli futtatása. Ennek előnye jelentkezhet a biztonság oldalon is, hiszen nem kellene ezt nagy rakás kódot ilyen magas privilégium-szinten futtatni.

Mivel KMS-re felkészített világban élünk (legalábbis ami az ATI és Intel hardverrel rendelkező felhasználókat illeti, az NVIDIA tulajdonosoknak pedig lassan érkezik a támogatás a Noveau fejlesztőktől), egész egyszerű az X szervert rábírni a speciális privilégiumok nélküli futásra. Jesse Barnes az Intel-től arról beszélt az X.Org listán, hogy a kívánatos eredmény eléréséhez mindössze egy kisebb patch szükségeltetik az X szerver oldalon, és még egy másik még kisebb, triviális változtatás a kernelben található Direct Rendering Manager-en. A fejlesztő tudja, hogy az X szerver patch jelenleg elég "hackelés" jellegű, ezért egyelőre csak véleményeket kért az ötlettel kapcsolatban.

A részletek itt és a Phoronix cikkében.

( bervi | 2009. 07. 04., szo – 16:07 )

naiv leszek, de startx-hez eddig se kellett root, csak a login manager-hez. valaki elmagyarázná ezt nekem? :)

szerintem.

user@gep / $ ls -l /usr/bin/X
lrwxrwxrwx 1 root root 4 2009-06-26 10:37 /usr/bin/X -> Xorg
user@gep / $ ls -l /usr/bin/Xorg
-rws--x--x 1 root root 2270416 2009-06-26 10:37 /usr/bin/Xorg

Az s -beture figyelj.

A startx is az X et hivja.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az X bináris nálad nem suid root?

Nem az a lényeg, hogy root indíthatja-e el, hanem hogy kinek a jogaival fut.

Eddig, mivel a hardware-t piszkálta, root jog kellett. Ezért tudta mondjuk egy X fagyás a gépet magával vinni.

Ha el tudják érni, hogy az X mindent a kernelen keresztül érjen el, akkor az X szerver futhat nem root-ként, és ha megborul, akkor a gép nem marad használhatatlan állapotban (feltéve, ha valami módon a kernel visszakapcsol azért valahová, pl. konzolra, vagy ilyesmi)

szerintem erről lehet szó
G

valószínű igazatok van.

Én csak abból indultam ki, hogy volt olyan, hogy az X befagyott, és fogta a display-t, a billentyűket hiába nyomkodtam, nem történt semmi. Besshzva lehetett rebootot tolni.

Azt gondolnám, (de lehet, hogy ez hülyeség), hogy ha az X megborul, de a kernel vezérli a video hardvert, akkor pl. egy konzolra váltásnak simán működnie kellene.

Persze lehet, hogy ez framebuffer óta is már megy, nekem az volt a tapasztalatom régen, hogy a karakteres konzolra sem tudtam átváltani.

G

Nem tudom. Valami olyasmi volt, hogy az X elváltotta a képernyőfelbontást, és konzolra visszalépve mintha függőlegesen szellemképes lett volna a kijelző... nem tudom, hogy magyarázzam jobban.
Szóval lehetett látni, hogy ott villog egy kurzor, lehetett látni, hány karaktert írtam be, de mondjuk elolvasni már nem lehetett, hogy miket.
root-ként login és reboot ment, de vacakolós volt.

De amióta framebuffert használok, ez nem fordult elő (mostanában az X is sokkal ritkábban fagy). Nem tudom, ha most sima karakteres módban lenne a konzol, fagyott X után vissza tudnék-e lépni.

Szóval lehet, hogy ez a probléma nem is létezik már 10 éve, de nekem ez jutott először eszembe róla, mert ezzel sokat szívtam.

Ennyi.

( Hiena v | 2009. 07. 04., szo – 17:24 )

Fasza, es minderre soha nem is lett volna szukseg, ha csinaltak volna kernelszintu grafikus kartya kezelest... Jah, bocsanat, azt nem lehet mert serti a Szent Linust...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Nem azt csinálják most éppen? KMS, GEM? Azután indultak meg ezek a dolgok, hogy az Intel kiadta az első komolyabb doksit. Meg most, hogy az ATI követte. Az NVIDIA meg azért habzik, mert a mai napig nincs dokumentáció. Szerencsétlen Nouveau-sok reverse engineering-gel próbálnak valamit bohóckodni, lassan haladnak, de ahhoz képest nem rosszul.

--
trey @ gépház

Nem egészen.
Annó még a XFree86 idejében is ez volt a helyzet, és 8-9 évvel ezelőtt nem csak 2-3 gyártó volt a piacon.
Dokumentáció is van/volt, ugyanis enélkül az X se menne. (Az X effektíve direktben piszkálja a vasat, többek közt ezért is kell rootként futnia.)
A fő kernelfejlesztők mereven elzárkóztak a fejlesztéstől, aminek az egyik oka az volt, hogy a korai kernel verzióknál pocsék volt a hardverdetektálás és a nagyeskü a monolitikus borzalomra lett letéve. Ehhez hozzájött a különféle grafikus módok kezelése közt uralkodó káosz. Közölték is, hogy a kernel csak a karakteres módot támogatja és csókolom. Ha pontosabb akarok lenni, akkor kb az állt a hátterében, hogy a karakteres módokat hardverfüggetlenül, szabvány bios hívásokkal lehetett inicializálni és kezelni.
A vicc, hogy ezt a mentalitást a framebuffer device-al tudták megtörni, ugyanis a régi Apple és Amiga gépeken nem volt külön karakteres és grafikus mód. A fbdev célja az volt, hogy ezeknek egy egységes felületet teremtsen a karakteres mód emulálására. Az már csak a sors fintora, hogy ugyanezen eszközön virit mostanában a tuxlogo, és emiatt van UTF8 a konzolban.A tuxlogon kívül a fbdev egyik előnye, hogy az X-et lehet futtatni a használatával gyakorlatilag egy kenyérpirítón is, és Xdriver bug (ATI tulajok figyelmébe) esetén ezúton is lehet grafikus felületet varázsolni a gépre.
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Láttam egyszer egy előadást, amit Keith Packard tartott, abban elmondta ezt. A dolog lényege, hogy kb. 15-20 évvel ezelőtt, mikor az XFree86-ot elkezdték csinálni, akkor nem volt hozzáférésük az akkor piacon lévő Unix változatok bináris kernelének doksijához és nem tudták, hogy az egyes változatok mit tudnak és mit nem. Emiatt csinálták meg olyanra, hogy az X csak olyan dolgokat használ a kernelből, amit minden OS kernel ismer. Ezért van külön driver minden eszközhöz, stb. Ma már ezt hibának tartják, de ennek átírása ha elkezdik, akkor is hosszú lesz. Ezért jelenleg együtt élünk vele.

Ha netán érdekel valakit, akkor itt van: X Community History

Az X szerver felépítésében a driveres megoldás választása mögött a platformfüggetlenség volt a fő indok. Az Xnek vannak olyan változatai (X-deep/32) amik nem *nix kornyezetben futnak, és ezeknek teljesen más driverekre van szükségük.
Itt az igazi probléma az egységes kernel szintűvideó API hiánya linuxnál.

--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Itt ketto teljesen kulon dologrol folyik a vita. Nem az a kerdes, hogy miert nem voltak kulonbozo grafikus kartyakhoz kerneloldali tamogatasok, hanem hogy architekturalisan miert nem ugy nez ki a dolog, hogy a grafikus reszt kizarolagosan a kernel kezeli, es az X az maximum szerenyen kerhet dolgokat. Ezzel szemben a kettos driver model divott, es az X userspace alkalmazaskent igen kemenyen beleszolt a kernel mukodesebe, ami eleg nagy _architekturalis_ baki.
Egy normalis rendszerben minden periferiaesemenyt a kernel kezel le, es a grafikus felulet csak egyfajta frontendkent viselkedik a kernel ele.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Tegyük hozzá, az nvidia drivere az egyetlen, amely valóban jól működik. Ahol igazából "mindegy" mit raksz fel, mert stabil és megy. Fogalmam sincs milyen verziójú nvidia driverem van, mert sosincs vele gond, nem kell piszkálni semmilyen téren... Néha megnézem, van újabb, letöltöm felrakom. Egyszerűen működik, még a betak is...
Ha rákeresel itt a fórumba is, ati meg intel driver problémából akad bőven, míg nvidiaval elenyésző.
--
Discover It - Have a lot of fun!

Nekem nem kell bemutatni az NVIDIA-t, gyakorlailag már akkor is használtam, amikor az MPlayer team folyamatosan cinkelte. Az 3Dfx megszűnése óta kizárólag NVIDIA kártya van az itthoni asztali PC-ben. Linux-szal is elég sokat használtam. Szóval nekem kell reklámozni.

--
trey @ gépház

Üdv!

Tehát ha mostanság akarok venni új notit akkor nvidia-t érdemes venni? Mert szüleim gépén az ati driver nem volt kifejezetten kóser (hmm még windows alatt is sokáig bugzott), nálam az intel videokártyás notimon 4 év után végre minden támogatottá vált egyszer csak az intel driver xar lett, mondhatni használhatatlan. Bármilyen disztrót rakok fel, villog a képernyő. Az új ppa driverrel meg minden nap csontra fagy az ubuntum. :(

Szeretnék majd új notit venni.. ezért kérdezem.

Az asztalim mindig is nvidia volt, ezt az alapján mondtam.
A laptopom ati... Az első, és biztos hogy utolsó ati-s gépem. 3 év alatt egyetlen driver sem volt, ami jól működött volna. Eleinte az a bár bug elviselhető volt, mondván majd kinövi, kijavítják. De nem, csak nőnek... Az utóbbi időben pedig szó szerint katasztrófa.
--
Discover It - Have a lot of fun!

Nekem Radeon7500 van a nótásban, a suspend hol megy, hol nem, véletlenszerűen. Amikor nem megy, akkor csak a kikapcs-bekapcs segít. Már nem merem használni mert nem tudom, mikor tud feltápászkodni és mikor hagy szarban. Többek között ezért van az, hogy én inkább a shutdownban és restartban hiszek, ellentétben trey-jel aki suspendel.

Inteles noti is volt, azzal minden szép és jó volt (kb. egy évvel ezelőttig biztosan).
---
;-(

( mrev | 2009. 07. 05., v – 08:53 )

Az X rendeltetésszerű használata:

X -query host1 :1
X -query host2 :2
X -query host3 :3

Ezután a CTRL-ALT-F7/F8/F9/F10 billentyűkkel lehet váltani 4 gép képernyője között (:0 az eredeti). Régen az X indításához nem kellett sudo, futni persze root jogokkal futott. Mostanában kitalálták, hogy biztosabb, ha a userek nem indítgatnak X-et (helyette esetleg Xnest, Xephyr). Olyan értelemben biztosabb, hogy ritkábban fagy le. Hasonlóképpen megszüntették, hogy az CTRL-ALT-BACKSPACE lelője az X-et. Ezek az új korlátozások azért bosszantóak, mert az X normális (lefagyásmentes) állapotba hozása helyett a funkcionalitást csökkentik. És feladják a fölényt, amit a kliens/szerver koncepció nyújtana a winnel szemben.

Egyébként gyakran lefagy. Gyakrabban, mint a kék halál. Tipikus szituáció, amikor az X szerver még fut, de a hozzá tartozó kliens hostot lekapcsolják.
--
CCC3

Nálam (Intrepid) viszont nem, és ez is mond valamit az X (és a Linux desktop) állapotáról. Úgy emlékszem, hogy különféle fórumokon elkeseredett viták voltak a CTRL-ALT-BACKSPACE-ről. Több dolgot javasoltak a visszaállításra, amik egyes esetekben működtek, más esetekben nem. Nekem mindegy, csak a jelenség és a tendencia érdekes.
--
CCC3

X -query localhost :1

Amíg az X szerveren a gdm képernyő van, addig a várt módon működik a dontzap on/off serverflag. A Gnome desktop feljövetele után a dontzap on/off beállításától függetlenül a ctrl_alt_bksp hatástalan. Teljesen normális konfigráció van nálam.

--
CCC3

Látom, többeket megérintett, hogy nem működik a ctrl-alt-bksp. A magam részéről jobb szeretem, ha működik, de nem tettem erőfeszítéseket az ügy érdekében. Nem ez fő probléma.

Úgy emlékszem a SuSE 9.0 volt az első, amelyik nekem ezt csinálta. Azóta többször oda-vissza változott a helyzet. Ha az előző megfigyelés igaz, akkor ctrl-alt-bksp letiltása nem az X ügye, hanem a desktopé. Viszont a desktop miért akar intézkedni egy olyan dologról, ami az X szintjén prímán paraméterezhető, és ott is van a helye? Akkor mindenki beállíthatná magának, ahogy akarja. De nem, mert a desktop fejlesztők jobban tudják. Ez viszont már probléma.

"kifejezetten hálát adok annak, hogy nincs alapértelmezetten"

Kerlek fejtsd ki bovebben. Gondolkoztam mar rajta, hogy miert jo az, ha ki van kapcsolva, de nem tudtam rajonni. Olvastam olyat, hogy sokan 'veletlenul' megnyomtak, es elveszett a munkajuk. Ez szamomra eleg hihetetlen, nem egy olyan kombinacio amit gyakran hasznalna az ember. Egyedul ugy tudom elkepzelni, hogy nehany laptop billentyuzeten, ahol kozel van egymashoz a del es a backspace, az ember a ctrl+alt+del helyett nyomja meg. De akkor meg ugyis ujra akarja az ember inditani a gepet, ha ehelyett csak az X-et inditja ujra az nem lehet baj.

Szoval miert orulsz annak, hogy ki van kapcsolva?

Már korábban leírtam. Virtuális gépben ctrl+alt+del-t akartam nyomni laptop-on, de helyette egy ctrl+alt+backspace-t sikerült. Nem nehéz ezt összehozni laptop-on. Az eredmény: kiugrott az X a virtuális gép alól, lehetett az egész hóbelevancot újraindítani, ami nem kis idő, stb.

Nekem NEM KELL. Ismerem más, kevésbé buta módját az X leállításának, elindításának, újraindításának ha kell. Egyébként sem értem, hogy egy ilyen 12345 milliomod rangú feature ki vagy be állapotban leledzése miért ilyen q fontos...

--
trey @ gépház

Oke, de ez nem egy popularis eset, azt ugye te is belatod? Ugy ertem, egyfelol kulturalt virtualis gepek a Ctrl-Alt-Del -t altalaban a Ctrl-Alt-Insert vagy hasonlo billentyure bindelik at (nalam vmware alatt ez Ctrl-Alt-Shift-Insert), masfelol eleve nem sokan foglalkoznak virtualis gepekkel.
Szoval, azt te is megtehetned, hogy default bekapcsolt beallitas mellett ezt tiltod, de ugyanakkor a tobbiek szamara nem feltetlen relevans ennek a szolgaltatasnak a ki vagy bekapcsolt allapota - ugyanakkor egy vis major hiba eseten jol tud jonni.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Tévedésben vagy. Nem az a kérdés, hogy jó-e vagy káros-e a ctrl-alt-bksp. Amiről egyébként elkeseredett viták vannak, és amiben nem akarok részt venni.

A ctrl-alt-bksp kérdése meg volna oldva az X-ben, lehet(ne) engedélyezni és tiltani izlés szerint, ahogy fentebb írták. Ezzel szemben a desktopok (windowson szocializálódott) fejlesztői egy más (nem konfigurálható?) szinten felülbírálják az X konfigurációt. Ez az, ami nem tetszik.

Emlékeztető: A gdm képernyőt még le lehet lőni az xorg.conf beállításától függően, azonban az Ubuntu Gnome desktopot már nem, akármi van a dontzap flagben.

Lehet, hogy a konkrét kérdés nem fontos, de mégis hiba, és a zagyvásodás/windowsosodás irányába mutató tendenciát jelez.

Miközben e fórum kapcsán a kísérleteimet csináltam, 3-4 alkalommal resetelősre fagyott az X. Ennek javítása helyett az X funkcionalitását akarják úgy lekorlátozni, hogy az egyszerű felhasználó kevesebbszer találkozzon a fagyással. Rövid távon ennek is van haszna, de ez a rövid táv már 10 éves.
--
CCC3

Ez most mar engem is izgat. Mi esszeru oka van ezt kikapcsolva tartani a "hagyjuk defaulton, biztos jo" hozzaallason kivul? Veletlenul eselytelen vagy megnyomni, a r=1 userek meg amugy se kepesek nagyon 3 gomb egyszeri lenyomasara.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nekem az első dolgom bekapcsolni ha Ubuntu-t telepítek. Nem egyszer jártam már úgy, hogy egy Wine-ban futó 3D-s alkalmazás rántotta magával az X-et, esetleg 1-1 általam elbarmolt Compiz plugin tette hidegre a gépet. Most néha még tty-re sem tudok váltani, mert.. fene tudja miért.

Szeretnem visszakapni az Ubuntu 7.04-es X-et, amikor ha fagyás volt, legrosszabb esetben átváltottam konzolra és kilövöldöztem a dolgokat. Most meg lehet rántja magával a rendszert is egy banyek alkalmazás..

Ez így biztos nem igaz.

Ez az xorg.conf-om:

ection "InputDevice"
Identifier "Generic Keyboard"
Driver "kbd"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "us"
EndSection

Section "InputDevice"
Identifier "Configured Mouse"
Driver "mouse"
EndSection

Section "Device"
Identifier "Configured Video Device"
Option "UseFBDev" "true"
EndSection

Section "Monitor"
Identifier "Configured Monitor"
EndSection

Section "Screen"
Identifier "Default Screen"
Monitor "Configured Monitor"
EndSection

most kipróbáltam, kiválóan működik.

Vagy nem elég új a rendszer? Melyik eleme?
xorg-ból 7.3 van

[~]$ pacman -Q | grep xorg
xorg-apps 7.4-2
xorg-font-utils 7.4-2
xorg-fonts-100dpi 1.0.1-2
xorg-fonts-75dpi 1.0.1-2
xorg-fonts-alias 1.0.1-2
xorg-fonts-encodings 1.0.2-3
xorg-fonts-misc 1.0.0-4
xorg-res-utils 1.0.3-3
xorg-server 1.6.1.901-3
xorg-server-utils 7.4-6
xorg-twm 1.0.4-3
xorg-util-macros 1.2.2-1
xorg-utils 7.4-4
xorg-xauth 1.0.3-1
xorg-xdm 1.1.8-2
xorg-xinit 1.1.1-1
xorg-xkb-utils 7.4-2