RFR(S): 8130910: linux/unix: hsperfdata file created in cwd and not cleaned up if /tmp/hsperfdata_<username> has wrong permissions

[Langer, Christoph]

Hi all,



I don't know if this mailing list is the right one for this issue. Let me know if I should post it elsewhere.



I have prepared a fix for an issue with /tmp/hsperfdata files.



Please review this change.  I also need a sponsor.



Bug: https://bugs.openjdk.java.net/browse/JDK-8130910

Change: http://cr.openjdk.java.net/~simonis/webrevs/2015/8130910/



The problem is that for creating a file in /tmp/hsperfdata_<username>, an fchdir to this directory is attempted. In case there's no execute permission on /tmp/hsperfdata_<username>, the fchdir fails. As its return code is not checked up to now, the process would stay in its current working directory and create the file in there. The location stored for cleaning up at the end of the VM is also remembered as /tmp/hsperfdata... so the file would remain left over eventually. There are several checks for the hsperfdata location in place but nothing would hit and prevent the fchdir attempt beforehand in this case.



I fixed it by handling fchdir return code and in case of failure closing the handles and returning NULL. In that case we wouldn't have shared PerfMemory but I think that is ok then.



I thought about a testcase but it would involve messing around with /tmp/hsperfdata permissions which can have effects on other running JVMs, too, which I consider a bit dangerous.



Generally I don't know if it is a good idea to do an fchdir at all but I don't know so much about the backgrounds of it... maybe someone wants to comment on that as well.



Thanks and best regards,

Christoph