In article <Pine.NEB.4.60.0411291424290.3140@himring.draga.com>,
Jim Wise <jwise@draga.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I have been looking at finally resolving the DoS attack noted in 
>/etc/defaults/daily.conf:
>
>  # calendar uses cpp to expand user calendars.
>  # calendar -a can be used as a local DOS by making an included file a
>  # named pipe, thus this is turned off by default.
>  run_calendar=NO
>
>Now, obviously, this could be done by denying users the ability to use 
>cpp on their calendar files, but this would be a mistake since 
>#include'ing the calendars of holidays in /usr/share/calendar is a very 
>typical use of calendar.
>
>This could also be solved by adding a rudimentary #include processor to 
>calendar(1) itself, but this would get messy fast, and would almost 
>certainly break some ways in which users use cpp directives in calendar 
>files.
>
>A third way to solve this would be to give cpp(1) the ability, 
>controlled by a command line option or an environment variable, to 
>refuse to parse any file which is not S_ISREG().  This would be easy to 
>add, since cpp already (at line 292 of cppfiles.c) skips any directory 
>which is #includ'ed, continuing to search the include path for the 
>specified file name.
>
>Doing this would, in addition, have general utility, since other 
>utilities which use cpp to parse untrusted input files could benefit as 
>well.
>
>What do people think?  Is this not worth touching the cpp sources for 
>(even given that such changes would be fed back to FSF)?  Does anyone 
>see another way to provide utilities the ability to parse untrusted cpp 
>input files safely?

That is the only way to fix this problem, so I say go for it.

christos