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.
If I wouldn't have been able to trigger a segfault with an adjusted file system, I would have skipped sending this patch for being just a bad fairy tale. But a crashing pacman on a broken file system sounds worse than a system with such a PATH_MAX -- and that still wants to use pacman. :)
What about simply using a predetermined buffer length? PATH_MAX isn't really the right size to use for this anyway, which is why POSIX defines SYMLINK_MAX. Since alpm's maximum path length is 1024, using a buffer size of 2048 or 4096 leaves plenty of room for symlinks to point to any alpm-managed file (assuming the link doesn't do anything bizarre like repeat "./" thousands of times). There could be valid symlinks that point to non-managed files that we won't be able to read, but that appears to be the case no matter what we do. apg