Re: GCC reporting piped input as a security feature

[Alan D. Salewski]

On 2024-04-08 22:37:50, Jacob Bachmeyer <jcb62281@gmail.com> 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
ads@salewski.email
salewski@att.net
https://github.com/salewski