Re: realpath(3)

[tlaronde%polynum.com@localhost]

Le Thu, May 25, 2023 at 09:57:55PM +0700, Robert Elz a écrit :
> 
>   | relying on programmers to test correctly the return
>   | status of a routine, is dangerous.
> 
> If that's your attitude you should stop writing any C code, as that's
> how it is done everywhere.  Functions that can fail indicate that in
> one manner or other, and it is the responsibility of the caller to check.
> 

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. It seems to me that when a problem is
detected, the attitude is not to say only: programmers should correct
their programs (as they should) but also to see if there is not a way
to make this faulty usage not a security risk considering the amount of
code and programs around that are unlikely to be corrected soon.

Someone knowing that some program in use has this bug and that
the program will happily construct a pathname
from chunks, not testing the return status, while one or several of
these chunks have invalid components, that is discarding problematic
components that have precisely permitted the pathnames entered by the
user to pass a first superficial inspection (for instance: not allowing
a pathname too "short", too "near" from root for example), so that the
program will finally open a file or directory that was not intended to
be accessed, is a question that lept to my (devious) mind---and please
don't start with "if you write such a code...": I don't!

Using resolvedname as the working buffer, as present, but overwriting,
only in case of error---you said it rarely failed...---with an invalid
path would protect from bugs in the usage while respecting the
POSIX.1 contract so that there is no change for programs that are
not specifically written for NetBSD: they don't have to use
resolvedname if error.

And having another NetBSD special routine, indeed used by the
realpath(3) wrapper so it is not duplicated work, providing the NetBSD
feature when this implementation defined feature is really used, is not
something unheard of.

But at least, it seems that we all agree that the mount instances and
pathadj() have to be corrected. This is already a great achievement for
a message sent by me.
-- 
        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