[lkml]   [1998]   [Jan]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: inode->i_count security hole
Bill Hawes writes:
> Alan Cox wrote:
> > > Looking forward to 2.0.34 (with idt mem leak fix? This could be used as a
> > > local DoS)
> > Actually you can do better than a DoS attack with it. The fix is to make
> > i_count a long at the moment.
> If this is being caused by excessive hard links, wouldn't it be easier
> to set some large but sane limit on the number of hard links allowed? A
> limit of 1000 or so would probably allow all legitimate uses but safely
> avoid any overflows. This would be easy to enforce in the link system
> call.

IF you do that per file-system, not at top-level!

I tend to think that 32000 links that EXT2 allows is wee bit
low limit -- but our web-server benchmark dataset is rather
weird anyway. (About 200 inodes of varying sizes, but million
names.. It gives rather pessimal figures, but they look
amazingly alike real system behaviour..)

> Regards,
> Bill

/Matti Aarnio <>

 \ /
  Last update: 2005-03-22 13:41    [W:0.038 / U:1.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site