Re: GCC reporting piped input as a security feature

Jan Engelhardt wrote:
> 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.
>   

And upon so stumbling, return ENOENT or ENOTDIR.  Where is the harm 
there?  Input read from a pipe does not exist in the filesystem.

> Better introduce a new DW_AT_ field for a stdin flag.
>   

That would mean that older tools could be confused.  How about a new 
field for "source-specified filename" when that differs from the actual 
file being read?  That way, existing tools would still see "[working 
directory]/<stdin>" and avoid confusion, which could be a security risk 
here.


-- Jacob