ls -1Itt lakik a HUP PartnerünkHUP tweetjeiNépszerű témákNépszerű fórum témákÚj felhasználók
|
libVTE visszagörgetési puffer probléma miatt érzékeny adatok szivároghatnak kiMark Krenz nemrég egy, a libVT 0.21.6-os és újabb verzióiban jelen levő, biztonsági problémát okozó tervezési hiányosságra hívta fel a figyelmet. Mivel a libVTE által implementált virtual terminal widget-et számos terminal emulátor - pl. gnome-terminal, terminator, xfce4-terminal, guake, evilvte, lilyterm, sakura, termit - használja, a probléma érinti ezeket a szoftvereket. A problémás commit-ot 2009. szeptember 7-én követte el Behdad Esfahbod. Krenz 2011. novemberében fedezte fel a fenti videón demonstrált hibát, majd hibabejelentést tett a GNOME Bugzilla-ba. Szintén jelezte a hibát Behdad Esfahbod-nak is, aki nem válaszolt a megkeresésre. Közben kiderült, hogy korábban már Daniel Gillmor felhívta Esfahbod figyelmét erre a gondra, de akkor Esfahbod azt közölte, hogy már nem szándékozik a jövőben fejleszteni a libVT-t. A probléma teljes leírása itt.
»
|
KeresésNavigációBelépésÁllásajánlatokHWSWFriss blogbejegyzések
HUP napi hírlevélInformációKövess minket! |
A betyárját... akkor ezért kerreg a winyóm, miközben ssh-val távoli gépen véletlenül cat-olok egy több száz megás logot :)
Link a Mark által reportolt bughoz:
https://bugzilla.gnome.org/show_bug.cgi?id=664611
Behdad Esfahbod is reagált.
+1
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/
"pl. gnome-terminal, terminator, xfce4-terminal, guake, evilvte, lilyterm, sakura, termit"
:) Ilyenkor jó, hogy Az Nagy Linuxos Változatosság az esetek 99%-ában kimerül a libek elé tolt frontendek változatosságában.
----------------
Lvl86 Troll
Felhasználói szempontból majdnem mindegy, ráadásul van egy pár nem libvte-s terminál is.
Azt nem tudom, hogy ebből mennyire lehet következtetéseket levonni más szoftvereket illetően. Az tény, hogy a médialejátszók elég nagy százaléka gstreamer vagy phonon, bár felteszem windowson se írja meg mindenki a saját kodekjeit meg minden mást, ami ehhez kell.
A másik eset pedig az, amikor minden project megírja a saját lib-jeit, és kb. ugyan arra a célra van egy rakás (pl. IM-kliensek). Szerintem ez még mindig jobb, főleg, ha jól karban van tartva az egy adott lib.
szerintem is csak olyan programot használjunk amit magunk írtunk más libek használata nélkül. írj meg mindent magad mozgalom (I4M vagy IM4. vagy IMMMM. majd a marketingosztály eldönti).
Gáz, persze, de erősen túllihegi ez a Mark.
--
joco voltam szevasz
Azért most eltűnődtem azon, hogy teszem azt, valahol jelszót vár a rendszer, a fókusz a terminálon van, figyelmetlenül becsépelem a jelszót, enter, s máris a bash history-ba íródott. Aztán history -c, de attól még a HDD-n ott van felülírásig.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
A bash nem azonnal írja ki a history-t, hanem kilépéskor. Ha véletlenül begépelek parancsként egy jelszót, reflexszerűen adom ki utána a "kill -9 $$" parancsot: a bash-t saját magát öletem meg úgy hogy esélye se legyen elmenteni a history-t. (Igen, a többi begépelt parancs is elvész, ez az ára.)
Ha kilépéskor ment, miért nem elég a history -c?
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Lehet, hogy elég, nem tudom. Sosem használtam ezt az opciót. A manuál alapján tök nem egyértelmű számomra, hogy az egész .bash_history fájlt gyakja felül (semmiképp sem szeretném), vagy csak a futó shell által eddig memóriába rakott bejegyzéseket. Ki kéne próbálni, előtte backup, nincs hozzá kedvem. Részemről azért kill -9, mert ez létező, máshol is használt, általam már ismert formula, tudom hogy mit csinál, tudom hogy azt csinálja atombiztosan amit szeretnék, nem kell hozzá se tanulni, se utánajárni, se gondolkodni, és kétségeim sincsenek hogy mi van ha félreértem, mi van ha bugos lenne stb. A history -c -re ezek egyike sem igaz, utána kéne járni, meg kéne ismerni, most még nem is vagyok benne biztos hogy jó lenne nekem, valszeg igen, de akkor is nem éri meg a belefektetendő utánajárást. Szerintem.
Kipróbáltam. Az aktuális shell történelmét törli. Felnyíl utána nem ad semmit, ugyanakkor az eddigi .bash_history megmarad. A shellből kilépve, újra elindítva a régi history elérhető.
Nekem a SIGKILL-el történő gyilkolászás eléggé ellenszenves. Elvarratlan szálak maradhatnak, nyitott file-ok, inkonzisztens állapot. Én csak szükség esetén nyúlok ehhez a barbár megoldáshoz.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Én is kipróbáltam, nekem legyakta az egész korábbi historyt. Pont erről beszéltem. Hogy nem tudhatom. A doksiból nem derül ki, bash verziónként vagy beállításonként változhat, kiismerhetetlen az összejátszása a többi éppen futó és később bezárandó bash process historymentésével stb.
A sigkilltől félsz, mert nem ismered. Nem maradnak elvarratlan szálak, sem nyitott fájlok, sem inkonzisztens állapot. Persze ha akkor nyírsz ki egy folyamatot amikor épp dolgozik valami fájlon, akkor az inkonzisztens maradhat az alkalmazás szemszögéből, de ha a bash-t saját magát saját magából lövöd ki, akkor nyilvánvalóan semmiféle függőben lévő fájlműveletet nem végezhet akkor.
Ha jok a megerzeseim, akkor csak a sajat gepemen tudom ezt reprodukalni.
Nalam minden titkositott particion van; a gepet pedig zarolni szoktam.
és ha screen-t vagy tmux-ot, dvtm-et futtatok a terminátorba benne, akkor mi van? :)
Asszem csinalok egy hasonlo videot, felteszek egy VM-be valamit, unlimited-re allitom a scrollback meretet, cat-olok valami jo nagy dolgot, es megmutatom, hogy a swaprol is kiolvashato (ugyanugy rendszergazdakent), esetleg a kcore-bol (na, onnan tuti).
Inkabb megsem, mert most nincs kedvem.
--
R2D2 a filmtörténet legmocskosabb szájú karaktere.
Minden szavát kisípolták.
+1
Remelem ez a Mark arc sem hasznal swap-et, nehogy diskre keruljon valami ideglenes adat ill. a ptracet is letiltotta.
Amit nem lehet megirni assemblyben, azt nem lehet megirni.
+1
Szerintem diszket sem hasznal, nehogy rakeruljon valami...
Az, ha valaki a sajat gepere nem figyel, mikozben sysadmin teendoket lat el rola, szerintem mar nem a libVTE developer(ek) hibaja.
~$ ldd /usr/bin/xfce4-terminal | grep vte
libvte.so.9 => /usr/lib/libvte.so.9 (0x00007fb44f10b000)
~$ ldd /usr/bin/gnome-terminal | grep vte
libvte2_90.so.9 => /usr/lib/libvte2_90.so.9 (0x00007fbedfa57000)
~$ ldd /usr/bin/konsole | grep vte
~$
A részleteket elolvastad? A konsole sem megoldás, mert ember számára ugyan nem olvasható, de triviálisan dekódolható formában ír HDD-re.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Viszont ez nem a VTE-s probléma, hanem egy saját fejlesztés, ez már egy másik problem ticket. :)
Annyira viszont nem triviális ez a fajta issue, hogy a "Testing and reproducing the issue"-ban leírtakkal tetten lehetne érni csak úgy.
A többi emulátor fejlesztőinek viszont most főhet a feje, mert Esfahbod már nem szándékozik a jövőben fejleszteni a libVT-t, tehát valaki másnak kell a hibát orvosolni. A konsole ezzel szemben egy elég virulens közösség eléggé központi eleme, vélhetően hamar orvoslásra kerül a probléma benne.
Upd.: úgy tűnik, a konsole csak akkor érintett, ha unlimited-re van állítva a scrollback. 10000-es scrollback-nél nem jön létre ilyen temp file a /tmp-ben. http://linux.slashdot.org/comments.pl?sid=2714201&cid=39288993
Most már elég legyen! Mindig szerkeszted, s már sokadjára olvasom a hozzászólásod. ;)
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Bocsesz! :D
Ubuntuban már javították is:
https://bugs.launchpad.net/ubuntu/+source/vte/+bug/778872