Ahoj,
Zbyněk Burget napsal(a):
Dan Lukes napsal(a):
> No, proc tam nabidnuty patch neni tam je vysvetleno - tato cast kodu se
vola i v kontextech kdy pouziti zamku (a tedy serializace jak jsem ji
popsal vcera) neni bezpecne pouzitelna.
To je sice hezke, ale pokud nekde neco dela nesmysly, bylo by dobre,
aby na to nekdo sedl a vymyslel to tak, aby to nesmysly nedelalo (vim,
to my tady nevyresime...). Sic se nam linuxaci zase budou smat,
protoze oni urcite tak hloupy problem nemaji.
Linuxaci se ti urcite smat nebudou protoze podobny problem obsahuje i
kernel linuxu...kdyz je dostatecne rychly loger :-D
Aspon ja sam jsem to pozoroval na 3 distribucich...gentoo,centos,
archlinux... ktere v soucasne dobe jeste dozivaji na nekterych mnou
spravovanych vecech...a upozornuju ze jsou upgradovane ty masiny :-D
Ten, kdo PR uzavrel si mysli, ze resenim je pouzit
options PRINTF_BUFR_SIZE=N
Pak, kdyz dojde k prokladani, tak nebude prokladano po jednom znaku,
ale po N. Reklo by se - staci vzit dostatecne velke 'N' a je v
podstate vyreseno. Ano, jenze ten buffer se alokuje na zasobniku a v
kernelu uz neni, rekneme, 128 byte (coz je hodnota, ktera se pro N
obcas doporucuje), zanedbatelne mala pamet. Tam se porad jeste hraje
o jednotlive byte (no, rekneme desitky byte).
Jak velke to N je ted (kde to zjistim)? Co se stane, kdyz to s
velikosti N prezenu? Existuje nejaky zpusob, kterak odhadnout ono N
tak, aby to clovek nemusel zkouset zvedat po jednom a v urcitem
okamziku pri onom zvyseni o jedna nedoslo k pruseru?
Zbynek
No jesli je ten buffer na zasobniku jak pise dan, mohlo by se mozna
jednat i o docela velky security leak ? Ale to teoretizuji...
A jesli je zkutecne tak tak ten pruser je zbynku asi docela na miste
predpokladat :-D
vilem
--
FreeBSD mailing list (users-l@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
