Re: GCC reporting piped input as a security feature

[Jan Engelhardt]

On Tuesday 2024-04-09 05:37, Jacob Bachmeyer 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
> [...]

This will likely backfire. Assuming you have a userspace program
which does not care about any particular substring being present, the
fullpath is passed as-is to the OS kernel, which *will* resolve it
component by component, and in doing so, stumble over the XXX/ part.

Better introduce a new DW_AT_ field for a stdin flag.

> 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.