RFR(xs): (jdk10) 8173828: realpath is unsafe

Dmitry Samersoff dmitry.samersoff at oracle.com
Tue Mar 14 09:00:47 UTC 2017



1121: It might be better to return ENAMETOOLONG

1131: It might be better to check for
      filename != NULL && outbuf != NULL before any call to realpath
      and return EINVAL for product and assert it for debug build.

1134: What is the goal of this assert? Do you see this problem?

1135: If realpath overwrites outbuf, strlen might have unpredictable

      So it might be better to set last byte of outbuf to 0 before
      call to realpath and check that it is still zero after call


On 2017-03-14 10:11, Thomas Stüfe wrote:
> Hi all,
> may I have reviews for this smallish fix.
> Issue: https://bugs.openjdk.java.net/browse/JDK-8173828
> Webrev:
> http://cr.openjdk.java.net/~stuefe/webrevs/8173828-realpath-is-unsafe/jdk10-webrev.00/
> In short, realpath(3) is unsafe the way it is traditionally used (with a
> user buffer provided). It is safe if used in the new POSIX.1-2008 compliant
> way. To wrap this behavior, I added a new os::Posix::realpath() function
> which takes a buffer and a buffer size (like a sane API would but the
> ancient realpath() did not) and moved safe buffer handling into this API.
> Kind Regards, Thomas

Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.

More information about the hotspot-runtime-dev mailing list