On Wed, May 05, 2010 at 11:05:18AM -0700, Garrett D'Amore wrote: > Thanks for the clarification. The concern I have is that while an > app can achieve the same resource exhaustion by opening multiple > files, we *do* have ways to limit the total number of open files > that an applications is permitted to have. By setting large values > here, and then opening and closing TCP sockets repeatedly, it seems > like these options might provide a (worsened) way to bypass those > resource limitations.
The app does not need an unlimited number of file descriptor numbers to do what Kacheong described. It can just keep opening new sockets to replace older ones, using say, a total of two or three file descriptor numbers. (You've done this manually, I'm sure: say you ssh somewhere, and then a packet loss spike causes your ssh connection to become unresponsive, so you start a new one and abandon the old one. I know I've done this, lots (it helps that I use screen(1).) > Admittedly, the damage here is limited to DoS executed from someone > who already has gained arbitrary code execution capability on the > system, but it still seems like this could be strengthened up a bit. I don't see how. > The existence of the options in current code doesn't necessarily > mean that the existing code doesn't suffer from the same flaw, and > exposing it more broadly by documenting the behavior may worsen the > situation. I don't think it does any such thing. Moreover, I think not having these options puts us at a disadvantage relative to competitors. Nico -- _______________________________________________ opensolaris-arc mailing list [email protected]
