Re: GCC reporting piped input as a security feature

[Jacob Bachmeyer]

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