Divne hlasky ve /var/messages

[Vilem Kebrt]

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