On Sat, Oct 10, 2026 at 04:00:07PM +0200, Martijn van Duren wrote:
> On 10/10/26 15:48, Stefan Sperling wrote:
> > On Sat, Oct 10, 2026 at 03:24:55PM +0200, Martijn van Duren wrote:
> >> Found by gcc-4 on alpha :-)
> >>
> >> As per POSIX, realpath() stores up to PATH_MAX into resolved, so let's
> >> make sure that that space is available.
> >>
> >> While here, gcc-4 complains about brackets arround '&', so why not
> >> please our ancient compiler overlords by placing said brackets. Diff
> >> below allows gotsysd to be build on alpha with -Werror.
> >>
> >> martijn@
> > 
> > There was some reason why -portable needs _POSIX_PATH_MAX instead
> > of PATH_MAX. Does _POSIX_PATH_MAX not work for us?
> 
> Yes and no. _POSIX_PATH_MAX is always 256 bytes, and a minimum for
> PATH_MAX (see POSIX's limits.h documentation). Since realpath()
> expects resolved to be at least PATH_MAX in size, which on OpenBSD
> is 1024 there's a chance we can overwrite up to 768 bytes.

Hmmpf. So something needs to be done.

The -portable problem with PATH_MAX is that not all systems define it.
It would probably be good to avoid any use of PATH_MAX for portability.

For instance, Linux expects this limit to be queried at run-time from
the sysconf subsystem:

 $ getconf PATH_MAX /
 4096

For realpath(3) specifically we can work around this problem by passing
NULL for the output buffer, forcing dynamic allocation of the buffer.
We already do this in many cases, all other ones need to be converted
to pass NULL.

We also make extensive use of PATH_MAX to define fixed-size buffers
in various imsg structures, for instance to transport the path to a
repository. Switching these to a dynamic size + data layout and a
corresonding amount of path data would be possible in theory. But the
imsg framework still restricts us to a (configurable) maximum message
size and I think enforcing some maximum, be it PATH_MAX or a custom
limit, still makes sense. We should probably just hardcode 4096.