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
