Hi Jeff,
"Jeff Epler" <[email protected]> writes:
> It is possible to specify a date format string that will produce truly
> unreasonable amounts of output:
>
> $ date +`python -c 'print("%2147483648c" * 10000)'`
>
> (the format string here is 10,000 repetitions of "%2147483648c"). This
> will produce around 20,000GiB of output (20TiB). On my system,
> producing 10 repetitions takes 33 seconds, so the full 10,000 would
> take about 9 hours. A repetition factor of 11000 did not work on my
> system due to the operating system limitation on the total size of
> arguments.
I wouldn't consider it a denial of service. It can be easily
interrupted by a signal, such as a SIGPIPE:
$ date +`python -c 'print("%2147483648c" * 10000)'` \
| head -c 1 | wc -c
1
If we used strtftime that would mean allocating 20TiB of memory and
then storing the resulting string, which would be a problem. However, we
use fprintftime which turns each individual format specifier into a
string and then prints it.
If someone wanted to redirect it to a file to fill your disks, they
could choose much quicker method:
$ timeout 5 dd bs=`getconf PAGE_SIZE` if=/dev/zero of=dd-output \
status=none
$ timeout 5 date +`python -c 'print("%2147483648c" * 10000)'` \
> date-output
$ ls -la --human-readable dd-output date-output
-rw-r--r--. 1 collin collin 1.5G Oct 26 23:15 date-output
-rw-r--r--. 1 collin collin 3.0G Oct 26 23:14 dd-output
> I noticed that another implementation of time (uutils) caps the field
> width of any given "resource specifier" at 255 characters, meaning
> that the biggest length of output is probably under 10MiB (but still a
> non trivial amount of output)
I would consider that a bug in that implementation (albeit low
importance). As Paul mentioned, we try to avoid arbitrary limits.
Thanks,
Collin
