Re: GCC reporting piped input as a security feature

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.

 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>

and:

<quote>
     4.13 Pathname Resolution
     ...
     A pathname consisting of a single <slash> shall resolve to the
     root directory of the process. A null pathname shall not be
     successfully resolved. If a pathname begins with two successive
     <slash> characters, the first component following the leading
     <slash> characters may be interpreted in an
     implementation-defined manner, although more than two leading
     <slash> characters shall be treated as a single <slash>
     character.
     ...
</quote>


[0] The Open Group Base Specifications Issue 7, 2018 edition
     IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008)
     Copyright © 2001-2018 IEEE and The Open Group

-- 
a l a n   d.   s a l e w s k i
[email protected]
[email protected]
https://github.com/salewski