Re: GCC reporting piped input as a security feature

Alan D. Salewski wrote:
> On 2024-04-08 22:37:50, Jacob Bachmeyer <[email protected]> spake thus:
>> Richard Stallman wrote:
> [...]
>>> In principle it could be posible to output something different to
>>> describe this stramge situation explicitly.  For instance, output "via
>>> stdin" as a comment, or output `stdin/../filename' as the file name.
>>> (Programs that optimize the file name by deleting XXX/.../ are likely
>>> not to check whether XXX is a real directory.)
>>>
>>
>> With the small difference that I believe the special marker should be
>> '<stdin>' (with the angle brackets, as it is now), this could be another
>> good idea.  Example output:  "[working directory]/<stdin>///[specified
>> filename]" or "[specified filename]///<>/[working directory]/<stdin>".
>> GDB could be modified to recognize either form and read the specified
>> file (presumably some form of augmented C) but report that the sources
>> were transformed prior to compilation.  The use of triple-slash ensures
>> that these combined strings cannot be confused with valid POSIX
>> filenames, although I suspect that uses of these strings would have to
>> be a GNU extension to the debugging info format.
>
> I do not think that the use of triple-slash (or any-N-slash) would
> entirely prevent potential confusion with valid POSIX filenames, as
> POSIX treats multiple slashes as equivalent to a single slash
> (except in at the beginning of a path, where two slash characters
> may have a different, implementation-defined meaning).
>
> Since a pathname component name can basically contains any bytes
> except <NUL> and <slash>, any token value chosen will likely have
> some non-zero potential for confusion with a valid POSIX pathname.

Yes, this is the downside of the extreme flexibility of POSIX filename 
semantics.  Any C string is potentially a valid filename.

> From SUSv4 2018[0] (update from 2020-04-30, which is what I happen
> to have handy):
>
> <quote>
>     3.271 Pathname
>
>     A string that is used to identify a file. In the context of
>     POSIX.1-2017, a pathname may be limited to {PATH_MAX} bytes,
>     including the terminating null byte. It has optional beginning
>     <slash> characters, followed by zero or more filenames separated
>     by <slash> characters. A pathname can optionally contain one or
>     more trailing <slash> characters. Multiple successive <slash>
>     characters are considered to be the same as one <slash>, except
>     for the case of exactly two leading <slash> characters.
> </quote>

Rats, I had forgotten that detail.  Emacs treats typing a second slash 
as effectively invalidating everything to the left, I remembered that 
some systems (and many URL schemes) use double-slash to indicate a 
network host, and I expected that 3 slashes would mean starting over at 
the root if that were ever presented to the kernel's filename resolution 
service.

On the other hand, we could use multiple slashes as a delimiter if GCC 
normalizes such sequences in input filename strings to single slash, 
which POSIX allows, according to the quote above.

The simplest solution would be to simply document and preserve the 
current behavior, which appears to be ignoring directives and recording 
the working directory and "<stdin>" in the case of reading from a pipe, 
and making sure that no normal build procedure for any GNU package pipes 
source into the compiler.


-- Jacob