On 11/08/14 07:50, Rob wrote: > On 8 Nov 2014 07:01, "Rob Landley" <[email protected] > <mailto:[email protected]>> wrote: >> >> getline() returns an arbitrarily long line. In theory _megabytes_ >> long, which it mallocs. Could this be a denial of service attack? ... > I don't know if this is an issue. If a user can run "grep blah > /dev/zero" then they have shell access anyway, what's to stop them > compiling a C program that allocates memory in a loop?
In theory a script could run grep on input from an http cgi or similar, so the input is user controlled. It's the sort of thing that _seems_ safe... but isn't. Again, I don't know what the correct response is. Since this is something posix-2008 picked up from the gnu/dammit guys, it is of course badly specified. (The FSF is a political organization with only a vestigial software engineering effort attached, neither programming nor documentation are anywhere near their core competency.) Specifically, the man page's "ERRORS" section doesn't even mention -ENOMEM (let alone -EPIPE or -EIO)... In an out of memory situation or with an input error could it return a _short_ line? Discard partially read input if an error occurred partway into a line? Wazzit do? I _suppose_ on a certain level this is really libc's problem. Or at least as much libc's problem as the user's. But "juristictional arbitrage" does not solve problems. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
