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

Daniel D. Daugherty daniel.daugherty at oracle.com
Wed Aug 19 14:37:19 UTC 2015


 >  I also need time to mull on the stuff down below.

Closing the loop on this part.


On 7/17/15 4:38 PM, Daniel D. Daugherty wrote:
> On 7/16/15 9:18 AM, Langer, Christoph wrote:
>> 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/
>
> src/os/aix/vm/perfMemory_aix.cpp
>     No comments.
>
> src/os/bsd/vm/perfMemory_bsd.cpp
>     No comments.
>
> src/os/linux/vm/perfMemory_linux.cpp
>     No comments.
>
> src/os/solaris/vm/perfMemory_solaris.cpp
>     No comments.
>
>
> I think I'm OK with the code changes above, but I need more
> time to mull on them. I also need time to mull on the stuff
> down below.
>
> Will get back to this next week.
>
> Dan
>
>
>>
>>
>>
>> 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 concur that the fchdir() error check is a good idea.


>> 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.

Since it's not necessarily safe to do the PerfMemory stuff if the
fchdir() fails, this is a good solution.


>> 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.

Yes, Jerry ran into lots of landmines with trying to create a test for
the original failure mode. I can easily see how tweaking permissions
in a test can mess up other Java processes running on the system.


>> 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.

This one is covered in a follow up email on 2015.07.17 to the
original review request.

Dan


>>
>>
>>
>> Thanks and best regards,
>>
>> Christoph
>>
>>
>>
>
>



More information about the hotspot-dev mailing list