Linux kernel file offset pointer races

Kernel

Paul Starzetz az ISEC Security Research tagja egy kritikus hibát talált a Linux kernelben. A hiba érinti a
A hibát felfedező szakemberek állítják, hogy tapasztaltak már olyat, hogy az ssh-n keresztül bejelentkezett root felhasználó jelszava megmaradt a memóriában.

A hiba bejelentése itt.

Ezt a hozzászólást nem értem...

- Ez most valami hülye BSD flame akar lenni?

- Vagy vmi. meg nem nevezett linux-kernelpatchra utaltál?

- Vagy csak simán szinvonalon aluli hülyeség, és meg se kellett volna írni ezt a hozzászólást?!

Bocsi, de így hogy az első kettőre nem történt konkrét utalás, és ameddig ellenkezője be nem bizonyosodik, addig kénytelen vagyok feltételezni, hogy te jösz ide "elitkedni" és hülyeségeket nyomatni...

Semmi koze az elitkedeshez, olvasd el figyelmesen azt, amire valaszkent irtam. Flame nem hinnem, hogy kerekedne ebbol, szanalmas agynelkuli megnyilvanulasok vannak enelkul is, lasd pcforum.

BSD-re utaltam.

A lenyeg az lett volna, hogy az illeto azert nem irta le a velemenyet, mert nem okosabb azoknal, akik irtak a linux kernelt. Nem kell elfogultnak lenni leginkabb.

Regebben linux kernel hibara irtam, hogy bsd powah :-) (smiley is volt a vegen). Erre megkaptam, hogy bsd kernelben is van hiba, url pastezva. Megsem kezdtem el pattogni, ahogy te tetted most.

Megegyszer a lenyeg, lassan irom, hogy megertsd: csak azert ne kritizaljon valaki valamit, mert nem tud olyat letrehozni?

Az elitkedes szerintem thuglife asztala :-)

Ez kész! kohinoor kontra thuglife - avagy eljött az ideje a HUP-arc szavazásnak!

Amúgy, hogy pontosak legyünk, azt te nem kernel hibára írtad, és ez nem teljesen mindegy:

Re: Befejeződött a Grsecurity fejlesztése (Pontok: 1)

Szerző: kohinoor Ideje: Június 01, Kedd, 09:20:52

BSD poWah :-))))

Ennek azért egy picit káröröm kicsengése volt, azt azért talán te is érzed. Nem lesz attól jobb a BSD, hogy a Linux rosszabb lesz. Sőt, ha a linux rosszabb lesz, és egyre többen fognak átállni *BSD-re, és akkor majd az lesz a script kiddie-k elsődleges célpontja. Akkor majd elválik, hogy mennyire igaz vagy hamis az a biztonság, amit a BSD-knek tulajdonítanak. Az elfogultságot nemcsak másban, hanem magadban is észre kell venni.

Hogy visszatérjünk a mostani cikkhez, szerintem nem lesz rosszabb a Linux attól, hogy biztonsági szakértők kereszttüzébe került. A bugok akkor is ott vannak, ha nem teszik közzé őket. A Linuxban és a BSD-ben is. Csak a linuxban most már eggyel kevesebb van.

Egyébként én már tényleg csak röhögök rajta, hogy amikor a linux kernelben találnak valamit, akkor mindig felbődülnek a fanatikus BSD-sek és benyomnak valami jó kis flamebait-et. Csak arra kell majd fogadni, hogy thuglife vagy kohinoor lesz az első...

2. gondolom bejelentés alapján megírták..

Amúgy meg sz'tem fogadd meg a secunia tanácsát, ha egy local "less critical" bug javítása ennyire sürgős..;)

Ha mindenáron elengedhetetlenül azonnal fontos és létszükséglet a 2.6 meg a hibajavítás, akkor

tedd a "userjeid könyvtárait" noexec-re (+tpe)...

A Thug csak ne elitkedjen, a 2.2-es linux kernelt nem érinti a hiba...:)

és a secunia statisztikája szerint a 2.2-es [secunia.com] kernelben 2002-2004 között kevesebb volt a bejelentett hibák száma mint az "openbsd kernel"-t érintőek...:)

thug, ugye kb. 6-7-8 obsd kernel bugot számoltunk a múltkor a 2.2.xben levő 4-el szemben?...:)

Jó ez persze viccesen hangzik, de a debian a woodyn keresztül a mai napig supportálja a 2.2-es kernelt.

(sőt asszem még a 2.0.x-hez is adtak ki idén javítást, de lehet rosszul emléxem.)...:)

és ha "megmaradnak a hagyományok", akkor sarge megjelenésétől számított 1 évíg ez még így lesz....:)

Most vonatkoztassunk el attól, hogy a 2.2.-es kernelt mennyien használják (meg hogy mennyire nem támogatja a mai vasakat), meg hogy az openbsd-t mennyien...:)

Ja igen, a közhiedelemmel ellentétben ebben a 4 darabban benne vannak azok a hibák is, melyek érintenek más kernelverziókta is . (pl. 2.4)..:D

Na ne mondd már! A probléma gyökerét itt kell keresni, nem pedig ott, ahol te keresed: én programozó leszek valamikor, és ezt a hozzászólást ennek fényében kell nézni, nem pedig úgy, mint egy felhasználó. És hogy a gyenge autós példával is megvilágítsam: A Dacia gyár elnöke mi alapon kritizálja a Mercedest, ha a saját járgánya jól példázza gyengébb képességeit. Ha olyan jól tudja, hogy kell jó autót csinálni, miért olyan gagyit csinál? Mert csak a szája jár.

Nem tobb eves dolgokrol kell beszelni hanem a jelenrol. Es az a grafikon teljesen ertelmetlen amit mutattal, ugyanis szamtalan linux kernel hibat nem tartalmazott. Szeretnem meg azt is megjegyezni hogy most a 2.6.x kerneleket egy ping6 al panicoltatni lehet es errol en meg egy advisoryt nem lattam, pedig mar fixeltek. Hany van meg amit fixeltek es amirol nem tudunk?

Bezony...bezony

Minden sikeres projektnek meg kell szenvednie a felnotte valast. Egeszen mas szemlelet kell egy nehany tizezres install base kiszolgalasahoz, mint egy tizmilliosehoz (es lehet, hogy meg ennel is nagyobbak a kulonbsegek).

Mi van, ha kiderul, hogy a fejlesztesi modell nem mukodik ilyen leptekben, mi van, ha egyre tobb hibat gyartunk (itt jar most a linux)? Mi van recsegnek az eresztekek a legacy design-ban (mert higyjetek el minden elavul egyszer)?

Mas kerdes, hogy a BSD meg gyerekcipoben jar, es nem tudom miert orulunk, hogy meg nincsenek felnottbetegsegei? Majd lesznek. Ha valaki szerint nem lesznek, akkor az nem felhasznalo, hanem hivo, a hivoket pedig messzire kell terelni a szamitogep mellol.

Amikor a BSD kernel es az app base eleri a Linux szintjet, akkor lehet osszehasonlitgatni, addig nincs sok teteje. Ezer peldat tudnek mondani (sot mar korabban mondtam is), ami hianyzik a BSD-bol es van a Linux-ban.

Hiaba a BSD-s ovisoknak nagyon fejlett a kritikai erzeke, de hogyismondjam nagyon egy adott celpontra van beallitva, es elegge szuk a fokusz.

Viszont tok jo, mert megmutattak, hogy milyen tok keves hiba van a BSD-ben. Az meg nem derult ki, hogy mire hasznalhato. Vannak ra programok, amikkel dolgozni is lehet? Nincsenek, de legalabb nem hibasak!

Whoa. Ez jo. Nem dolgozunk majd a cegnel, aztan majd akkor a hibatlan OS miatt nem tornek be hozzank.

Andrei

Itt mar nagyon elkanyarodtunk a lenyegtol, valoszinuleg az en hibambol. Mint nyilvanvalo, elfogult vagyok, mindenki reszrehajlo, es ha pont abba rondit bele valaki, amit preferal, akkor megy a haddelhadd. Engem ez nem erdekel. Mindenben/mindenkiben lehet hibat talalni, ez sem erdekel. Ezeket nem gondolom at ilyen esetekben. Van egy agyonhype-olt rendszer, a linux, amivel sokat foglalkoznak, sok a bug benne, amit talalnak. Eppen forditva kene lennie.

Talan az volt a baj, hogy leirtam a linuxrol a velemenyemet.

Eleg lett volna annyi, hogy: csak azert nehogy ne mondjon valaki velemenyt, mert nem tud jobbat/ugyanolyat letrehozni. Ehhez tartom magam. Demoscene-t is biraltak sokan. Kivulallo vagy, qss. Vege is lett, mint a botnak, halott. Par komodoros meg pacskol, aztan sziahello. Es ebben benne van az elitkedes es a kritizalas momentum is.

Ez a thuglife plane nem foglalkoztat, nem tekintem versenytarsnak, egyszeru vegleny. Alant olvastam, hogy a a linux2.2 mennyire jo, keves bug, stb. Hat igen, akkor kifejezetten jobb volt az egesz, mint most a csapongas a 2.6-ban...

Nem tobb eves dolgokrol kell beszelni hanem a jelenrol.

Szerintem minden olyan progi, amire van (security) support, azt lehet jelennek tekinteni használat szemponjátból, ha az adott vason elfut.

Ennek ellenére nyílván egy csomó olyan vas van, amin 2.2 már nem fut el.

Hany van meg amit fixeltek es amirol nem tudunk?

Ezért mondtam bejelentett hibát. Bejelentett hibák szempontjából grafikon.

Es az a grafikon teljesen ertelmetlen amit mutattal, ugyanis szamtalan linux kernel hibat nem tartalmazott.

Hát most vetettem egy pillantást a 2.4es kernel hibákra, hogy mi hiányozhat.

Így ránézésre r128, iptables, ieee, e1000, cpufreq, usb vicam driver kapásból nincs bent (vagy csak nagyon régi) a 2.2.-ben. Sz'al bejelentett hibákat tekintve a grafikon sz'tem korrekt képet mutat.

Szeretnem meg azt is megjegyezni hogy most a 2.6.x kerneleket egy ping6 al panicoltatni

Én se látok ilyet. Jelentsd be, és akkor lesz. :) de ez nem csak 2.6.0-test(X?)-nél volt meg?...

vagyis még kiadás elötti verzió ? nem lehet ezért nem volt bejelentve?

ha érintette a 2.6.0 végleges verzióját akkor igazad van. eggyel több a 2.6os "kernel hibák" száma.

ha tényleg csak egy tesztevrzió volt érintett, akkor megkérdem, pusztán az összehasonlítás kedvéért, az obsd "teszt"-verzióiban még a "kiadás elött" talált hibákat is "bejelentik"?

De pl. Securityfocusos összehasonlítást is lehet csinálni, hátha ott "nyílvántartják".

Mar evek ota ezt hallgatom, hogy "ha egy kicsit tobben kezdenek foglalkozni bsd-vel akkor mennyivel tobb bugot talalnak majd abban is". Az evek alatt a bsd userek szama megtobbszorozodott, de sokkal tobb security alertet nem latok. Tevedes ne essek, nem a bsd-t akarom fenyezni, egyszeruen ugy gondolom, hogy a bsd-nel nem az esznelkuli fejlesztes, az egyre tobb uj hardver tamogatasa meg az utemezok es memoria kezelok valtogatasa a fo szempont, hanem egy jol atgondolt komplett rendszer karbantartasa, ahol az elsodleges cel meg mindig a kiszolgalokon valo stabil, megbizhato mukodes es nem az egyre gyorsabb es tobb filerendszernek a tamogatasa meg az utemezok folyamatos lecserelgetese nemi kisebb latencyert.

Ebben azert nagy szerepet jatszik az is hogy nem tesztelik és nem nezik at tisztessegesen a beerkezo diffeket. Azzal nem lenne problema, hogy tobb utemezo is van vagy 50 fs csak minosegi legyen, nem pedig egy osszeganyolt massza. FreeBSD is kezd ebbe a hibaba esni es nap mint nap latom ahogy eltavolodnak az emberek es ternek at DragonFlyBSD re vagy egyeb masra.

Azt probalom hangsulyozni, hogy OpenBSD mindent bejelent.

Tehát ha a 3.5teszt0-s (nem'tom obsd-ben eztet hogyhíják, de remélem világos milyen "fejlesztési állapot"-ra gondolok!) verzióban volt egy hiba, de a teszt1-esre kijavították, akkor azt is bejelentik?

Tehat az senkit nem erdekel, hogy OpenBSD 2.x ben hany kernel hiba van.

Én arról a két "grafikon"-ról beszélek, amiben az egyikben a "supportált" linux 2.2.x-re bejelentett hibák, a másikban az obsd 3.x-re bejelentett hibák vannak.

A linux 2.2.-re kevesebb van ua. időtartamban, mint obsd 3.x-re.

Mas kerdes, hogy a BSD meg gyerekcipoben jar

Bocs, te mirol beszelsz? Az elso BSD kiadas 1977-ben jelent meg, a Linux tortenete meg 1991-ben kezdodott...

Amikor a BSD kernel es az app base eleri a Linux szintjet, akkor lehet osszehasonlitgatni, addig nincs sok teteje.

??? Linuxnak nincs is app base, mert a Linux csak egy kernel. Vagy melyik disztribúcióra gondolsz? BSD kernel mikor eri el a Linux szintjet? Bugok tekinteteben remelem soha... Mellesleg mikor lesz a Linux kernelben olyan jail megoldas, mint a FreeBSD-ben? Az hogy a Linux tobb hangkartyat tamogat engem nem nagyon erdekel.

Vannak ra programok, amikkel dolgozni is lehet? Nincsenek, de legalabb nem hibasak!

Milyen programra gondolsz amit hasznalsz es megy Linuxon, de nem megy BSD-n?

Te olyan vagy mint a thuglife, csak te tenyleg komolyan gondolod amiket irsz... ;)

Nincs itt szo semmifele tesztverziorol... A thuglife egy olyan hibarol irt 2.6.x-ben amit meg a 2.6.7-es kerneleknel is kilehet hasznalni, viszont 2.6.8-rc2-ben mar nincs benne. A masik kerdes meg az, hogy ha a 2.2.x-es linux kernelben levo bugok es a 3.x-es openbsd bugok lettek osszehasonlitva akkor az openbsdben szinten csak a kernel bugok kerultek osszehasonlitasra vagy pedig a teljes rendszer userlandel egyutt. Mert ugye ez nem mind1. A masik, hogy azert feature szempontjabol, nehogymar a 2.2.x-es linux kernel tobbet tudjon, mint a 3.x-es openbsd...

A masik kerdes meg az, hogy ha a 2.2.x-es linux kernelben levo bugok es a 3.x-es openbsd bugok lettek osszehasonlitva akkor az openbsdben szinten csak a kernel bugok kerultek osszehasonlitasra vagy pedig a teljes rendszer userlandel egyutt.

Csak a kernelt számoltuk !...

Sz'al ez úgy kezdődött, hogy thuglife ránézésre az obsd grafikonosra, félszemmel 4-et saccolt, én erre felsoroltam neki amit "kernelesnek gondoltam" (mivel nem ismerem a bsd-t, ezért megkértem hogy számolja csak a kernelt), és ő meg számolta a kerneles hibákat. így jött ki kb. 6-7-8- már nem emléxem pontosan - obsd kernelre.

A masik, hogy azert feature szempontjabol, nehogymar a 2.2.x-es linux kernel tobbet tudjon, mint a 3.x-es openbsd...

Hát pecselni a 2.2.x-et is lehet...:) PaX pl. van 2.2-re (csak i386-ra), méghozzá egészen friss

A vas támogatás (hw, filesystem) az már más tészta.

Ha olyan vasad van, amiben obsdhez van driver, de 2.2höz nincs ott nyílván a 2.2.es linux nem összehasonlítási alap, csak akkor ha a vassal mindkettő elmegy.

A 2.4-es és 2.6os kernelben viszont lényegesen több a bejelentett hibák száma, mint az obsd 3.x "kernelben" .

Nincs kedvem utanajarni, de szerintem a 2.2.x kernelben joval tobb bug volt mint 4... ;)

Nézd ha a között kell választanom, hogy secunia statisztika, vagy "hunger szerint", akkor az előbbinek hiszek..;). viszont nyitott vagyok, érvekkel meg lehet győzni az ellenkezőjéről.

Mar a ptrace alapu exploitokbol is tobb van 2.2-re szerintem.

Expolit lehet éppen több is, ha mind ugyanazt a biztonsági hibát használja ki. (csak másképpen, stb.)

persze mint mondtam ha találsz még 2.2-t érintő biztonsági hibát akkor vedd úgy,hogy meg vagyok győzve.

(de még azonkívül még kell 2-3 darab, hogy elérjük az obsd "bugszintet". ;)

U.I.:

Még mindig "nyuszi" vagyok obsd-t telepíteni.

Linux kernel 2.2.26 Changelog [www.kernel.org]

2.2.26

------

o CAN-2004-0077: behave safely in case of do_munmap() (Solar Designer)

failures in mremap(2)

o CAN-2003-0984: /dev/rtc can leak parts of kernel (Solar Designer)

memory to unprivileged users (2.4 backport)

o CAN-2003-0244: hashing exploits in network stack (David S. Miller)

...

Linux kernel 2.2.22 Changelog [www.kernel.org]

Security Fixes

- Multiple numbers of potential sign handling, maths overflow and

casting errors were fixed. Some of them are theoretically locally

exploitable.

Linux kernel 2.2.19 Changelog [www.kernel.org]

Itt annyi van, hogy inkabb csak kiemelnek nehanyat:

Security Updates

binfmt_misc

binfmt_misc touched user pages directly and could be exploited.

CPIA driver

An off by one buffer check in the CPIA driver allowed users to

scribble into kernel memory

CPIA driver

An off by one buffer check in the CPIA driver allowed users to

scribble into kernel memory

SYS5 shared memory

A code path existed where the shm code would scribble on very

recently freed memory. It is not clear that this was actually

exploitable.

sysctl

Mishandling of sign bits in sysctl allowed local users to

scribble on kernel memory.

Tighten packet length checks

The masquerading code checks were a little lax in some cases.

None of these are believed actually exploitable however.

User access asm bug on x86

Certain obscure constant copies came out copying the wrong

number of bytes. No known exploit or actual problem case is

known but it potentially existed.

...


Ez csak 3 Changelog a 26-bol. Te most melyik 4 bugra gondolsz? ;)

Aszongya 2.2.19 az még 2001-es (2001.03.25)

A 2.2.22-es pedig 2002.09.16 kiadású

A vizsgált időszak pedig 2002-2004. A secunia első "publikálása" 2002.09.02-i .

Úgy látszik ezek még vagy ezelöttiek voltak, vagy a secuniások akkortájt még nem voltak naprakészek.

Tehát akkor 2.2.26osok.

A statisztikát ezek alapján készült:

CAN-2002-1380

CAN-2003-0127

CAN-2003-0028

CAN-2004-0077

Úgyhogy a többi felvetésed szerintem jogos.

A secunia statisztikája kalap szart sem ér.

Csak itt [www.debian.org] elég sokat soroltak fel.

Sz'tem BSDből is kihagyhattak jópárat.

Changelogok szerint kellene megnézni akkor...(persze csak ha van kedvetek hozzá, hogy tiszta vizet öntsünk a pohárba)

Csak hát egy csomó nyitott kérdés van ...:)

mikortól nézzük? mert ugye a obsd-k supportált életciklusa linux kernelhez képest igen alacsony.

mondjuk lehetne obsd 3.4 kiadásától kezdve nézni a 3.4+ vs. 2.2.es kernelt. (mivel mint mondtátok a 3.4 még supportált). és kizárólag changelogok alapján.

Én linuxra a debiant javaslom, mert abban mint a linken is látszik, jól számolhatóak a bejelentések.

obsd kernel hibák számolására is van hasonló changelog?

Kedves Andrej!

Fogalmam sincs honnan szedtél össze ennyi baromságot,

de tudod amikor valaki tények nélkül hülyeségeket állít,

de nem hoz konkrét példákat, akkor azzal eléggé lejárattatja magát.

Az meg a másik dolog, hogy itt prédikálsz az "elvakult BSD hívőkről"

miközben én úgy látom rád is el lehet ezt mondani, hogy a linuxot magasztalod az egekbe, miközben valótlanságokat állítasz a BSDről.

Szóval tisztelettel csak annyit kérek tőled máskor talán

látogass mondjuk el a http://www.freebsd.org-ra

és nézegesd meg kik és mire használják a bsdt.

Nagyon el fogsz csodálkozni...

Mert nem ovisok...

Ennyit a gyerekcipős, meg az "egy adott celpontra beallitva, szuk fokusz" blamázsra.

Nincs elég program BSDre? :D

Erre sztem reagálni sincs értelme.

Én nekem semmi bajom a linuxal, de igenis szabad akaratomból használok mint desktopra, mint szerverre bsdt, és nem szégyenlem még előtted sem... Bocsáss meg érte!

Kövezz meg az "elvakultságomért"! :DDD

Akkor összegezzük:

1. jelenleg az obsd 3.4, és obsd 3.5 a supportált

2. ha jól látom akkor

az obsd 3.4-et 2003.10.30-án adták ki.

Akkor a linux 2.2-es, 2.4-es és 2.6os kernellel való összehasonlítás alapját

innentől kell számítani.

mondjuk az nem valószínű, hogy 0% bsd tapasztalat, tudás birtokában ki tudom szűrni

ezek közül a "csak kernel" hibákat:

http://openbsd.org./errata.html

http://openbsd.org./errata34.html

A 3.4esből (2003.10.30-2004.05) kb. 006,003,005,010,011,013 tűnik kernel bugnak, de mindenképpen javítsatok ki, mert tényleg nem ismerem a bsd felépítését.

A 3.5ösből kb. (2004.05-) kb. 005,006,010,014...

de tényleg javítsatok ki.

nemnemnem!!!

Erre figyeltem...

Csak 3.4-et 2004.05-ig néztem, amíg a 3.5-öt ki nem adták.

Utána párhuzamosan néztem, és valóban innentől majd mindenhol

minkét verziót érintette a hiba. Csak az egynek számoltam én is.

Ha más gond nincs, akkor ez így lett összesen 10 darab. 6 a 3.4-ből, 4 a 3.5ből.

Linux 2.2-ben (2.2.25-2.2.27pre2) az adott időtartamra csak 3-at találtam:

CAN-2003-0244

CAN-2003-0984

CAN-2004-0003

Ez kevesebb mint a harmada az obsd-ben levőknek.

Na kezdjuk, bar anno mar egyszer leirtam:

- Matlab meg mindig nincs (ezt megkerdeztem a fejlesztoktol is), emulacioban talan (10% esely) elfut, de errol meg senki nem beszelt. Viszont ha elindul, es elszall rajta a cuccod, akkor nem segit senki sem neked, azt fogjak mondani, hogy hasznalj rendes OS-t.

- Maya (tovabbmegyek Maya plugin-ek)

- Mathematica

- CAD programok (pl. BoCAD),

...

- Es meg egy par nyalanksag. Gyorsitott nVidia es ATi driver? nVidia van x86-ra, de nincs AMD64-re, ATi driver meg egyaltalan nincs. Es ha megfeszulnek a FreeBSD fejlesztok, akkor sem lesz. Csak akkor lesz, ha a fenti cegek ugy dontenek es megirjak.

Sorolhatnam tovabb, de a fizetos programok nagy resze BSD-n csak emulacioban, unsupported modon fut. Es ez problema. A biciklibolt Apache szerveren nem. De mondjuk egy millios projekt SAP szerverenek leallasa eseten kinos, hogy nincs support.

Pl. en a Linuxtol sem vagyok elajulva ugy en-bloc, de egyes reszei igenis figyelemremeltoak, es olyan technikai folenye van a kernelnek, ami a BSD-ben evek mulva kerulhet be, ha bekerul (NUMA-SMP, ccNUMA, ).

Mi is fut azon a szerveren, amit uzemeltetsz? MySQL (Postgres)-Apache-tuzfal? Mar ne haragudj, de ez 2004-ben nem fegyverteny. Fail-safe v. load balance Oracle clusterek uzemeltetese is megy? Probaltad? fogadjunk nem.

Na ilyen problemai vannak manapsag egy rendszermernoknek, a kernel hibakat pedig patcheli szepen, mint a kisangyal. Igy valamekkora kockazattal kepes megoldani a problemajat.

Az meg hogy tizenezer csomag van a ports-ban nem valtoztat a tenyen, hogy az OS elterjedtsege nagyon alacsony. Az install base fogalma azt jelenti, hogy hany peldany fut szerte a vilagban. Es hidd el ezen a teren a Linux nagysagrendi elonyben van.

Az en terminologiamban a BSD ovisok, azok, akik egy linux kernel hiba eseten feltetlen reflex-el "a *BSD rulez" valaszt fogalmaznak, nem pedig az OS fejlesztoi, akiket oszinten tisztelek.

Andrei

- FreeBSD Handbook kulon targyalja hogy kell Matlabot telepiteni [www.freebsd.org].

- Mayat komoly ember nem hasznal Linuxon, viszont MacOSX-en annal inkabb (egyebkent min alapul a MacOSX?).

- FreeBSD Handbook: Installing Mathematica [www.freebsd.org]

- CAD programokat megintcsak nem hasznal a kutya sem Linuxon, mar bocs...

stb.

Kedves Andrei!

"- Matlab meg mindig nincs (ezt megkerdeztem a fejlesztoktol is), emulacioban talan (10% esely) elfut, de errol meg senki nem beszelt. Viszont ha elindul, es elszall rajta a cuccod, akkor nem segit senki sem neked, azt fogjak mondani, hogy hasznalj rendes OS-t.

- Maya (tovabbmegyek Maya plugin-ek)

- Mathematica

- CAD programok (pl. BoCAD),"

Ezzel tulsagosan vitatkozni nem tudok,

mert szemelyesen nem probaltam ezeket, de most majd kifogom...

de handbook szerint:

"This document describes the process of installing the Linux version of MATLAB® version 6.5 onto a FreeBSD system. It works quite well, with the exception of the Java Virtual Machine™ (see Section 10.5.3)."

Ebbol szamomra nem az tunik ki hogy

annyira szarnak ertekelnek a fejlesztok a helyzetet.

"The Linux version of Mathematica runs perfectly under FreeBSD however the binaries shipped by Wolfram need to be branded so that FreeBSD knows to use the Linux ABI to execute them."

Ebbol sem azt vettem ki hogy hudesuxx

meg se probald...

Ha megis az lenne, bocs, akkor jogos,

szemelyesen telleg nem ellenoriztem meg.

Az emulacios dolgok pedig nem feltetlenul

rossz minoseguek (lasd linux alatt Cedega,

ami megbizhatobban futtatja a nativ win32es jatekokat mint a winxpm!!!)

CAD...

Tokeletesen igazad van.

Teny hogy vannak e teren (oriasi)hianyossagok.

"- Es meg egy par nyalanksag. Gyorsitott nVidia es ATi driver? nVidia van x86-ra, de nincs AMD64-re, ATi driver meg egyaltalan nincs. Es ha megfeszulnek a FreeBSD fejlesztok, akkor sem lesz. Csak akkor lesz, ha a fenti cegek ugy dontenek es megirjak."

Nos ez is teny, de szerintem ne szerencsetnel BSD-n verjuk le a port hogy ezen cegek _meg_ nem irtak megfello drivert alajuk.

Amennyiben kizarolag ezen dolgok nem megletet, akarod kihangulyozni, ugy sajnos itt is tokeletesen igazad van, de halkan

tennem hozza, errol tenyleg nem a BSD tehet, mert ha lehetove tennek ezen cegek szamukra hogy drivert irjanak mar reg megtettek volna... binary drivers "rulez" :(

Remelhetoleg e teruleten hamarosan elorelepes fog tortenni...

Telleg nem futtatok Oraclet, eltalatd :)

Tudom mi az installbase fogalma, es azt is tudom hogy a linux ebben a tekintetben is magasan vezet, de sztem ez onmagaban meg _NEM_ negativum.

Akkor kezd negativum lenni, amikor a fenti programok nativ tamogatasa, es a binaryonly-driverek nem meglete szinte kizarolagosan ezen tenybol fakadnak. Mert ez van sajnos. Ezek csak akkor keszulnek el, ha vagy megnyitjak a specifikaciokat, vagy a cegek eleg penzt szimatolnak hogy maguk elkeszitsek erre platformra.

Szoval amiket irtal abban egyetertunk mindketten, de valahogy nem erzem azt hogy a BSD barmit is tehetne sajat reszerol az ugy erdekeben, most a third-party fejlesztokon van a sor...

Tisztelettel: `RaVeN

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu.html

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/linuxemu-oracle.html

Ittvan oracle, ha annyira akarod, megy azis, dedicated CS server is, stb. Szerintem linuxot nem tudod felskalazni annyira, hogy esetlegesen Oracle-t hasznalj. Talan SGI Altix pumpalhato fel akkora teljesitmenyure, hogy nagy ceg is hasznalni tudja. Komoly cegek meg linuxot se hasznalnak, hogy miert, azt nem tudom. Vesznek Sun masinat, Oracle 0.5TB ram, aztan sziahello. Nem fognak linux-szal pacskolni. Persze BSD-vel sem. Ez van. A grafikusok pedig altalaban Windows alatt dolgoznak, esetleg ujsagiro szamitogepen (mac). Utobbi meg mindig jobb a pc-nel, de peldaul aki hasznalt mar Maya-t IRIX alatt, az tudja, hogy az arra lett irva kiskezicsokolom. Mind a Linux, mind a Windws verzio hagy kivannivalot maga utan, es ez ervenyes a Macre is.

Mindig az adott kornyezet donti el, mit erdemes hasznalni. Ahol security kell, megbizhatosag, skalazhatosag - oda nem pc alapu oprendszert fognak venni es nem pc-t fognak hasznalni. Lehet ugy is nezni a dolgokat, hogy a pc univerzalis akar lenni, tehat sokmindenre jo, azaz semmire sem igazan.

( snq- | 2004. 08. 08., v – 22:19 )

"...hogy tapasztaltak már olyat, hogy az ssh-n keresztül bejelentkezett root felhasználó jelszava megmaradt a memóriában"

csodalatos

( vmiklos | 2004. 08. 08., v – 22:25 )

4 nap alatt készült hozzá javítás? :S

( thuglife | 2004. 08. 08., v – 23:03 )

Csak en erzem ugy hogy ez mar kezd tenyleg nevetsegese valni?

Igen, ezt irtak ok is. Felulirja 0-val.

"We have found in an experiment that after the root user logged in using

ssh (in our case it was OpenSSH using PAM), the root password was keept

in kernel memory. This is very suprising since sshd will quickly clean

(overwrite with zeros) the memory portion used to store the password."

Sohasem ertettem ezt a fajta hozzaallast. Bizonyos korokben az megy, hogy ne mondjal velemenyt, csak azert, mert te nem tudod ugyanazt letrehozni, csinalj jobbat, vagy kuss bameg. Na ezt szerintem el kene felejteni. Nem kell ahhoz mernoknek lenni, hogy belassuk, egy auto csokker vagy nem, rossz allapotban van vagy nem. Ha veszek autot, nyomok egy probautat. Aztan megmondom a tulajnak, ha gazos, jobban tenne, ha kivenne a kocsibol a biztonsagi oveket, mert valaki hatizsaknak nezi, es felveszi/elviszi.

Ha nem muxik a rendszer, mert valaki ennek a kernel bugnak koszonhetoen legyalulja a halozatot, akkor a fonok joggal mondja, hogy ez a rendszer, amit csinaltal, *****. Erre azt mondod, csinaljon jobbat? Ugyan. Szamtalan pelda van meg, az elitkedes nem visz elore ebben az esetben, igenis ki kell mondani, hogy ez a linux kernel egyre fosabb es a linux is. Es nem csinalok jobbat, mert mar van :-)