Subject: Re: Option to make cpp(1) not accept named pipes or devices as include
To: None <>
From: Christos Zoulas <>
List: tech-toolchain
Date: 11/29/2004 20:41:47
In article <>,
Jim Wise <> wrote:
>Hash: SHA1
>I have been looking at finally resolving the DoS attack noted in 
>  # 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 
>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 
>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.