[pacman-dev] [PATCH] Prevent stack overflow on symbolic link access.

[Andrew Gregory]

On 06/06/16 at 08:27pm, Tobias Stoeckmann wrote:
> On Mon, Jun 06, 2016 at 01:27:52AM -0400, Andrew Gregory wrote:
> > Since we're already talking about unlikely scenarios...  My reading of
> > readlink(2) and readlink(3p) suggest this might still run into
> > problems on oddly configured systems.  POSIX leaves up to the
> > implementation what happens if bufsize > SSIZE_MAX and nothing
> > guarantees that PATH_MAX is less than SSIZE_MAX.  
> 
> That is true, in fact we would have to check if PATH_MAX is defined
> at all. If it's not there, we actually would have to call path_conf
> to figure it out. And even then it might be -1 to show that we really
> have no limits at all.
> 
> But on the bright side, "currently" this is proven by reality to be
> no issue, after all nobody filed a bug report for his system, that
> pacman does not compile. ;)
> 
> Same goes for PATH_MAX being larger than SSIZE_MAX. As long as we can
> trust the system that SSIZE_MAX really states the largest value for
> an ssize_t and that it has the same size like size_t, we would have
> run out of stack space looong before even reaching this function
> call.

I don't follow your logic.  SSIZE_MAX is only guaranteed to be at
least 32,767.  PATH_MAX can easily be larger than that without coming
close to exhausting my system's resources.

apg