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