Unix-gyűlölők kézikönyve online elérhető

meg a hulye duma, hogy linux-user egyetemistak irjak az osszes windowsos virust.

kapják be.

En is szerettem volna letolteni... Lassan befejezek egy Hofi konyvet.

Kell az utanpotlas. ;-) Bar ketlem, hogy osszemerhetoek.

Error: Access is Denied.

Neked sikerult?

Aha!

Except that I've removed the link while waiting for the brou-ha-ha on Slashdot to die down.

Köpjetek le, de abban az időben azért volt benne némi igazság... Mégha nem is kell mindent készpénznek venni.

Nem akarlak tamadni, de szerintem nem azt irja, hogy ez a ket fajta embre letezik, csak azt, hogy az ilyen emberek adnak igazat a szerzonek (vagy akik nem ismerik egyik, masik, vagy egyik op.rendszert sem).

Azert engem is elegge feldult a tartalomjegyzek.

Tudom, hogy nem kellene komolyan vennem, de amikor a itt-ott sajat hibaikat kenik a masik op.rendszerre az mar pofatlansag...

Udv,

KoS

Na ja...

Persze, ha nem olyan ''elérhetõ'' áron adták volna az oprendszert anno a gépekhez, akkor lehet, hogy a ''gazdag'' egyetemek nem állnak neki mindenféle Un*x-ot gyártani maguknak, és így nem kellett volna '94 körül, a core decus-osoknak így keseregve nosztalgiázniuk...

Persze, errõl nagyrészt nem õk tehetnek... A Digital, meg írhatja Win alá a Pathworks-öt :-D

Amúgy remélem 2006-ban megjelenik egy Linux-gyûlölök kézikönyve, ahol a Windows-osok keseregnek hasonlóan azért, mert a 'Suck' Linux teljesen lenyomta a WinFo$ tábort, és a néhány hardcore Windows-os már csak így, keseregve tud nosztalgiázni... :-) Persze a WinFo$ és a VMS nem említhetõ egy lapon...

Amúgy a VMS is tud édi-bédi meglepiket okozni, épp pár napja szívunk egy olyan esettel, hogy egy újraindított tûzfal miatt a negyed óránként induló és azonnal elhalálozó NTP démon visszaállítja az idõt. Kilõni, configot váltani nem lehet, mivel azonnal elhalálozik :-D, valószínû jön a reboot... Szóval, ezen egy Un*x-os csak mosojogna... így :-) , sõt így :-D .. Amúgy az X mit csinál, monduk egy Risc6000-bõl? egy 12MHz-es 286-ost?? (Hehe, mintha VMS-en is lenne X...)

Zsiráf

Right.

Eloszor is, elnezest kerek az indulatbol elkovetett troll-like

hangvetelert. Masodszor, velemnyem szerint van helye kritikanak a

unix-szal szemben, es inkabb orulni kellene annak hogy valakik sokat

ilyen szepen osszeszedtek egy csokorba: ez lehetoseget teremt arra, hogy

valaki feltegye maganak a kerdest "miert is van ugy ahogy, miert jo ez?

hogyan tudnek ez-es-ez ellen vedekezni?".

A konyvben leirtakkal sok helyen nem ertek egyet (latszik hogy kb. 10

evvel ezelotti valtozatokra irtak), de azt hiszem nehany helyen valoban

problematikus pontokra talaltak, amelyek alapvetoen meghatarozzak az OS

milyenseget (bourne shell, C, "minden file", hierarchikus FS, terminal

kezeles, suid/sgid, symlinkek: hogy csak nehanyat emlitsek az idejetmult

vagy idetlenul kidolgozott dolgokbol).

Csak a "kritika" szó szerintem ütközik a "hate"-tel.

"My name is Don Hopkins, and I'm a hacker. But not the evil kind that breaks into computers, steals credit card numbers, patents software, or works for the NSA. I'm into user interface and graphics programming, research and design. For fun I create and play with interactive graphical toys."

Szerintem meg tök jó, hogy minden fájl.

Nem kell külön norton gósztot vennem csak azért, hogy tudjak egy vinyóról imaget készíteni, és esetleg azt visszatölteni, mert hogy a partació is csak egy fájl virtuálisan, még ha azt /dev/hda1 néven is lehet emlegetni....

Magyarul alapfunkcionalitásokra, amik már a 20+ évvel ezelőtti rendszerben megvoltak, ma M$-en külön pénzt kell áldozz és célszoftvereket vegyél...

De ha te mondod, akkor neked elhiszem, hogy ma ez a trendi, és ezt kell tenni, és minden más elavult...

De én meg egy konzervatív ember vagyok, és jobban szeretem a régebbi jól bevált technikákat, mint a bleeding edge -> subject to crash dolgokat.

Az en privat velemenyem:

Az hogy minden file, az szamomra egy renkivul nagy elonye a unix szeru rendszereknek. Nagyon sok helyzteben jon nagyon jol (ahogy gyu is leirta).

suid/sgid is jol jon, csak esszel kell hasznalni.

A symlinkekrol meg csak annyit, hogy kb fel eve hallottam (csak hallottam, ezert nem biztos, hogy igy volt, de azert leirom), hogy windozekenal valamelyik nagy fej rajott arra, hogy mi lenne ha nem kellene 1 file-t tobbszor letarolni, hanem valami modon 1 helyen lenne, es tobb helyrol el lehetne erni... Na ez az ember se latott me'g eleteben unix szeru OS-t (@#@Q#!). De azert a tobbi nagy nagyfej is jo otletnek tartotta (amikor ez unix szeru OS-ek alatt mar miota letezik).

Udv,

KoS

Oh my. Ne kossunk mar bele a betonba is..

Regi, jol bevalt != automatikusan elavult, de potencialisan az.

Bleeding edge != automatikusan remedy, de potencialisan az.

Gondolkozz, miket hasonlitasz ossze! Egy cat /dev valoban nagyszeru

arra amit irtal, de ez sehol sincs ahhoz kepest amire egy Ghost kepes.

Nem a semmire adsz ki penzt. Persze lehet tovabbfejleszteni, egesz

szoftverkornyezetet koreepiteni, de akkor megint ott tartunk hogy penzt

kell kiadni. Olyan nincs hogy ingyen vacsora.

Nem rossz hogy van /dev/hda. Lehet belole olvasni, lehet bele irni.

De *semmi* masra nem alkalmas. Ha van egy CD-lejatszod, nem tudod

altalanos celu parancsokkal mondjuk a talcat ejectelni, mert ez egeszen

egyszeruen nem resze a tradicionalis UNIX infrastrukturanak. ioctl-lel

lehet izgatni, de akkor mar *teljesen* mindegy hogy kulon syscall-t

hasznalsz-e.

A plan9-ban erre kinalnak egy szep megoldast, sajnos tapasztalatbol nem

tudom mire jutottak vele, de a koncepcio izgalmasnakl latszik.

De szabad vacsora van ;b

Biztos van az észjárásodban valami nagyszerű, amit be is fogok ismerni, amint elmagyarázod nekem, hogy egy olyan dolgot, mint a tálca kiadása, miért egy általános célú parancsal akarsz megoldani?

A tálca kiadása, egy CD-romra specifikus dolog, és nem az eszközök egy általános tulajdonsága. Az eszközökre szépen le lehet kérdezni, hogy ejectable-a média, és ha igen, akkor az ejectelést lehet ugyanazzal az ioctl-el csinálni.

És attól még hogy cdeject-nek hívják a parancsot engem nem különösebben zavarna, ha a zip floppy-mat is ki tudná adni...

A nincs ingyen vacsora imho megint egy jó elszólás... Csak nem itt, hanem egy mestint vizsgán ;P

BTW.: Mit is tud a ghost, amit én ne tudnék pár unix parancsból , és a /dev/*-ból összelegózni? Mármint a szines szagos grafikus felülettől tekintsünk el, mert az lehet csinálni bármihez. Ellenben mivel "legó"elemeim vannak, linux legó elemeivel meg tudok olyanokat csinálni, amit a ghost nem.

Engem nem zavar, de jobban nem zavarna, ha vmi. olyan feature is lenne, hogy a sütimben, vagy vhol eltárolná, hogy melyik cikk hozzászólásait mikor olvastam, és az újakat valahogyan jelezné, mint ahogyan a debianplanet-en is van...

De ne legyünk telhetetlenek, trey szabadidejében portálozik, mintahogy mindenki más is :-)

Kedves KoS, gyu es tobbiek,

Ha megengeditek osszefogva valaszolnek a kritikatokra.

suid/sgid: en nem tartom tobbre egy quick&dirty hacknel. Teljesen

felboritja a user/owner szemantikat, mert ezt alkalmazva egy programra

ugy fog tunni mintha a masik user futtatna azt, es ennek kovetkezteben

szert tesz annak identitasara. Ennek latvanyos kovetkezmenye a

legalabb 3 (linux alatt 4) fele uid es gid: real, effective, saved

(fs) es a veluk jaro gorcsoles hogy mikor melyiket szabad figyelembe

venni, melyikre hogyan szabad valtani, mi az amit megse lehet

megtenni... Bonyolult, prone to errors, ganyolas.

symlinkek: hasznos hogy vannak, de mennyi elore nem latott problemat

felvetettek a nem alapos tervezes miatt! Az FS egy alapkoncepciojat

kezdik ki, nevezetesen a hierarchikussagat -- egy symlinket tartalmazo

FS ugyanis mar *nem* hierarchikus. Hangsulyoznom kell, nem a

letezesukkel van bajom, remek otlet, hanem a kiforratlansagggal:

bonyolult es inkonzisztens annak az eldontese hogy "na most ez a

syscall kovesse-e vagy se", es ennek eredmenye a rengeteg temporary

file creation/race condition vulnerability. Az olyanok mint a grsec

javitanak a helyzeten ebbol a szempontbol, de szebbe nem teszik.

A rendszer eldocog, de messze van attol hogy jonak lehessen nevezni.

"minden file" es device fileok: ugy erzem ezen a ponton felre lettem

ertve. Jo otlet volt annak felismerese hogy van egy csomo dolog

amibol alavetoen csak irni/olvasni akarunk. De ezt mara tulhaladtuk,

ez most mar keves. Tulajdonkeppen mindig is keves volt -- ezert

talatak ki menekulesi utvonalnak az ioctl-eket.

gyu irta, hogy nem erti, miert akarom altalanos celu parancssal

vezerelni a CD drive-ot, neki tokeletesen megfelel a cdeject is.

Valaszkent meg en nem ertem hogy ebben az esetben mire jo hogy

egyaltalan van nekunk /dev/cdrom-unk? Kit erdekel hogy a cdeject

azon a fileon matat vagy valamilyen kulon syscallt hasznal?

Ha ezt tennenk, csorbulna az altalanossag, ami mindenkinek ugy

tetszik. En amellett erveltem, hogy orizzuk ezt meg es

*altalanositsunk tovabb*, igy meg tobb hasznos scriptet irhat maganak

mindenki kedvere.

Ami a ghostot illeti, nezd meg a Symantec product description oldalat,

ott minden bizonnyal kimerito valaszt kaphat az erdeklodo a kerdeseire

(modulo a marketing junk, de ez elkerulhetetlen). Ha teged kielegitenek

a sajat magad eloallitott megoldasok, csodalatos, de azt eros

ketelkedessel fogadnam hogy egy par szaz soros scripttel te megegyezo

funkcionalitasu termeket hoznal letre. Ha megis megtenned az nem szaz

sor es nem fel nap volna, hanem sokkal hosszabb ido. Magyaran koltseg.

Erre jegyeztem meg, hogy nincs ingyen vagyora: ezt vagy penzben fizeted

meg, vagy munkaban.

Szabad vacsora van, de csak addig amig van kin eloskodni. Valakinek

dolgoznia is kell.

Szerintem pedig a suid/sgid egy nagyszerű ötlet volt Ken Thompshon-tól. Azt nem mondom, hogy mindenre megoldás, és minden igényt kielégít. Ezért pl. hasznos lenne, ha vmi. acl-szerűség alapból lenne a linuxban, mint amit pl. az rsbac ad. De attól még a suid/sgid nem hülyeség. Ha meg vki. nem tud programozni, vagy lusta nem jól használni ezeket a lehetőségeket, az ne programozzon.

A szimlinkekkel kapcsolatban szintén hasonló állásponton vagyok: nagyszerű lehetőség, és a race conditionok megint user space beli programozói hibák, nem a kernel/unix/posix rendszerek hiányosságai!

A CDeject problémakörre visszatérve pedig: ha egy újabb syscall-t hoznál be a CD ejectelésére, akkor még egy csomó mindenre behozhatnál egy csomó syscall-t és a végén annyi lenne, hogy átláthatatlan lenne. Imho elég ötletes/szellemes ez a ioctl dolog. Vsz. hacker agy szüleménye, mert egy már meglévő interfészt használt fel a dologra, és nem hozott be evvel újabb hibalehetőséget. Pl. belegondoltál, mennyi "egyéb" syscall kellene ahhoz, hogy a CD ejectelést syscall-on keresztül kérdezd le? Minden ejectable médiát le kellene tudjál kérdezni, infókat kéne tudjál begyűjteni róla, stb. És kéne tudjad ejectelni...

Igen, viszont ha saját magadnak csinálod, akkor motiválva vagy, hogy megcsináld.

Ha meg másnak, akkor meg ne ingyen csináld :-)

És ne feledd, avval hogy közzéteszed, amit csináltál, még nem leszel kevesebb. Ha másnak ugyanazt kell megcsinálnia, amit te egyszer már megcsináltál, akkor az a más kénytelen lesz a te doksidat elolvasni, stb. Vagyis ő se nulla munkával ért el eredményt.

Azt hiszem kimeritoen meggyozodtunk arrol hogy nem ertunk egyet :)

Osszegzes keppen megismetelnem, hogy a rendszer eldocog, de nem a

legjobb. Nehany dolgot korulmenyes megoldani suiddal es symlinkekkel,

nehanyat egyaltalan nem is lehet. Irnek ezekre ket peldat:

-- temporaty file letrehozasa kozos jatszoteren:

az open("/tmp/akarmi", O_CREAT | O_EXCL) nyilvan nem jo, mert az

open koveti a symlinkeket. Mit tehet az alkalmazasfejleszto?

mkdir("/tmp/valami", 700");

open("/tmp/valami/akarmi", O_CRRAT);

rename("/tmp/valami/akarmi", "/tmp/valami/akarmi", "/tmp");

rmdir("/tmp/valami");

Miert jo az hogy a user spacet ilyen idetlen trukkokre

kenyszeritjuk? Meg lehet csinalni, de ez nem a Right Thing.

linux alatt van O_NOFOLLOW, dehat az csak ott van.

-- setuid: azt szeretned hogy a /bin/foo vegrehajtasakor a userx

user1 jogosultsagaival birjon, de azt nem akarod hogy magat

a /bin/foo-t tudja modositani. Ezt suid segitsegevel egyszeruen nem

lehet megoldani, megha bedobjuk a soba a posix acl-eket is.

Ezen kivul ha a /bin/foo bugos akkor userx kontrollt szerez a tobbi

/bin/foo process folott is, ami altalaban nem kivanatos.

Azt mondod, aki tokosen tud programozni az nem fog bugos /bin/foo-t

irni? Lehet, de ehhez neked, mind sysadminnak biznod kell a

fejlesztoben (hogy valoban tokos es nem szurja el). Egy security layert

vesztesz el.

Ami a cdejectet illeti, egyik helyen azt irod hogy nem jo ha kulon

syscallt adunk neki, de ugyanakkor az ioctl-t jonak tartod.

Holott minden egyes ioctl maga is syscall (csak lassabb), tokmindegy

hogy az opcodeot az ax vagy bx regiszterben adod at a kernelnek.

Es az egesz tenyleg attekinthetetlen. Ezert nem adnek neki kulon

syscallt, hanem inkabb azt mondanam hogy ``echo 1 > /dev/cdrom/tray''

es a kriptikus TIOCSIFADDR-szerusegek maris atalakulnak ertheto,

strukturalt, egyszeru eszkozokkel hozzaferheto opertaciokka.

(A setuid bit egyebkent DMR szabadalma)