Re: realpath(3)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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.

  | Using resolvedname as the working buffer, as present, but overwriting,
  | only in case of error---you said it rarely failed...---with an invalid
  | path

Depending upon what you mean, either there is no such thing, or that is
already what is happening.   The path left there is the one that failed.

  | 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.

Nor do NetBSD programs - just they can, if they know what they're
doing (which would be a very specialised program I think).

The problem here was simply not understanding that realpath() can fail,
(or the connotations of that perhaps) as it rarely ever does.

The passed in buffer is going to have something in it when realpath()
returns NULL, that's the nature of arrays in C, they can't simply be
made to vanish.  I don't really understand why you believe that what
is there now is any worse than anything else which could be put there.

  | But at least, it seems that we all agree that the mount instances and
  | pathadj() have to be corrected.

There's nothing to do to all the mount_xxx programs, the way pathadj() is
defined, it must succeed.   If that can't happen, its only choice is to
abort the program, and exit.   That is what I have just made happen.

The other issue you mentioned, about lost memory if the adjusted path
was passed in as a NULL can't happen here - the only way to get the
result from pathadj() is to pass it a buffer to store the result in.
Passing NULL would be a waste of time, as there would be no way to
ever see the result (pathadj() doesn't return it, other than via that
parameter).

Other callers of realpath() who might pass in a NULL 2nd arg need to
arrange to free the result (or simply exit the program, freeing everything)
but that's not relevant here.

kre