- A hozzászóláshoz be kell jelentkezni
- 2524 megtekintés
Hozzászólások
0. (signalok tiltasa)
1. fork()
2. bezar minden ami nem kell
3. execve()
Miert nem jo, biztonsagi szempontbol?
- A hozzászóláshoz be kell jelentkezni
0. fork tortenhet sighandlerbol is, tehat ez fabatkat sem er, nem beszelve arrol, hogy ettol meg nem lesz thread-safe
2. az app nem tudhatja, hogy milyen fd-ket nyitott meg egy lib alatta (amiket a lib hivatott eldonteni, hogy at kell-e adni a gyereknek vagy sem)
- A hozzászóláshoz be kell jelentkezni
0. akkor signal handlerbe teszed a tovabbi lepeseket, threadek nem erdekelnek fork utan zarok.
2. bezar mindent, max hiba jon vissza ra, ill proc fs is megmondja.
- A hozzászóláshoz be kell jelentkezni
proc fs is megmondja
juj
- A hozzászóláshoz be kell jelentkezni
ja, hogy te nem a cimben szereplo cikkrol beszelsz. hat nyilvan ha a te kontrollod alatt van minden kod (konyvtarakat is beleertve), akkor lehet ugy is csinalni, ahogy akarod. de altalanossagban, amirol a cikk is szol, az FD_CLOEXEC a megoldas, meg amit most hozzaadtak a kernelhez.
- A hozzászóláshoz be kell jelentkezni
Ja, de ezen flagek ertelmes hasznalata is minden fd-t letrehozo kod modositasat jelenti.
Es siman nem teheted meg, hogy beletolod minden libbe, mert akkor jonnek az instabil API trollok.
- A hozzászóláshoz be kell jelentkezni
nem minden fd-t letrehozo kodot kell modositani, hanem minden FD_CLOEXEC-et hasznalot, ami azert nem ugyanaz (mondhatni sajnos, mert valoszinuleg sokkal tobb helyen kene hasznalni, mint ahol van jelenleg).
- A hozzászóláshoz be kell jelentkezni
jogos
- A hozzászóláshoz be kell jelentkezni
Kíváncsi lennék, hogy állnak ezzel a kereskedelmi UNIXok...
- A hozzászóláshoz be kell jelentkezni
Hacsak nem lesz megint egy nagy per, nem tudjuk meg egyhamar. ;-)
- A hozzászóláshoz be kell jelentkezni
A man page-eikben nincs benne.
lwn uzenetei szerint masok closefrom()->fdwalk()->procfs library hivast hasznaljak hasonloan, mint ahogy en irtam az elso postban.
Jo lenne, ha tobbi rendszerbe is bekerulne, akkor nem karognanak, hogy mar megint Linux-only kodot irt az ember :)
glibc -ben el lehetne fedni kulonbsegeket, figyelmeztetve az embereket, hogy nem minden glibc-t hasznalo rendszeren egy rendszer hivas lesz a vegeredmeny.
Aminek viszont orulok, hogy kivetelesen a biztonsag novelese (ill. fd eroforrasok hatekony kezelese), most csak pozitivummal jar, gyorsabb kod, egyszerubb tervezes mellett :), ha masok is atveszik esetleg POSIX-ozodik az meg jobb lenne (hordozhatosag).
- A hozzászóláshoz be kell jelentkezni
omg wtf?
--------------------------
The OOM killer is like a surgeon that amputates the limb of a man to save his life: losing a limb is not a nice thing, but sometimes there is nothing better to do.
"Understanding the Linux Kernel" on page frame reclaiming
- A hozzászóláshoz be kell jelentkezni
14400-on modemezek, úgyhogy nem tudom megnézni a linkeket.
A child processz indításakor nem lehet tudni, hogy milyen fd-ket kell(ene) lezárni. Azért nem lehet, mert más szálak (amik egyébként böcsületesen állítgatják az FD_CLOEXEC flaget) tarthatnak éppen az open és az fcntl között. Vagyis egy rosszkor induló child örökli az fd-t, hiába az fcntl. Ilyen dolgokat szinkronizálni is elég kényelmetlen.
Emiatt kérnek olyan támogatást, hogy az open képes legyen eleve nem öröklődő fd-ket csinálni.
--
CCC3
- A hozzászóláshoz be kell jelentkezni
"Emiatt kérnek olyan támogatást, hogy az open képes legyen eleve nem öröklődő fd-ket csinálni."
Nem is értem, hogy másoknak ez miért kérdés.
Még sokkal több olyan kernelszintű szolgáltatás kellene, ami a multithread programozást segíti.
Egyszerűen sok dolgok user kódban csak workaroundolni/csúnyán hekkelni lehet, megoldást a kernel-szintű támogatás nyújthat.
- A hozzászóláshoz be kell jelentkezni
Peldaul mire lenne szukseg meg?
Esetleg tudsz valami peldat problemas esetre amin kernel szinten lehetne segiteni?
- A hozzászóláshoz be kell jelentkezni