Re: realpath(3)

[tlaronde%polynum.com@localhost]

Le Fri, May 26, 2023 at 12:53:03AM +0700, Robert Elz a écrit :
>     Date:        Thu, 25 May 2023 18:04:28 +0200
>     From:        tlaronde%polynum.com@localhost
>     Message-ID:  <ZG+HDN7yYurMUpz8%polynum.com@localhost>
> 
>   | Again... If I have sent the message to security, it's because the wrong
>   | use of the routine (not testing the return status) could perhaps lead in
>   | some cases to a security risk.
> 
> Not really here, mount only works run by root, if you're running as
> root, there are far easier ways to do almost anything that attempting
> to fool mount into doing something weird in this obscure way.

But yes, there is a security even if it is not in the way I was originally
searching it: race condition.

Process A calls realpath(3) without verifying the result and takes
resolvedname as granted. But resolvedname is not the resolved initial
path, but a subdir that does not exist.

Then process A goes to sleep.

Another process, in the mean time, creates this subdir.

Then process A awakens and (in this example) mounts with a subdir or
a resource that has strictly nothing to do with what was intended...

And on a "linguistic" level:

I guess that a lot of people (me included) are parsing "realpath()" as
"giving the real path". But it is wrong: I see know that it must be
parsed as REALize PATH: do walk the path given to see if this route,
perhaps going and backing up (/..) reaches an accessible resource. If
the path succeeds, give the URI of resources (discarding the path chosen
to reach it).

This is what the implementation does (and it seems to me quite right)
but it is not what POSIX describes...

From the POSIX description, one could provide an implementation that
first "reduce", syntactically,  the "somedir/../" and, after, verifies
if there is a symbolic link in the resulting string.

And this is definitively not the same thing:

walking /usr/not_existing/../lib/libc.so will not get you to libc.so,
while "/usr/lib/libc.so" (reducing "/not_existing/../") is indeed an
existing resource.

And in case of existing symbolic links, going through the symbolic link
or not will not get you at the same place relatively to '..'! So by side
effect, the implementation seems to be the only way to achieve sanely
the result, but the POSIX description is not on point.

Still with a very fine comb: the NetBSD realpath(3) man page should
perhaps be corrected to replace "copies" with "stores" (the verb used in
susv4) because it seems to tell something about the implementation (and
it happens it is wrong: the implementation doesn't construct the result
in some internal buffer and then copies the result). And nonetheless the
implementation details are not part of the contract.

In this case, exceptionnally, IMHO (I'm not an english native speaker).
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C