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

[Gerald Thornbrugh]

Hi Dan,

> > Yes, I will sponsor the change. I'll also run it through our
> > internal testing infrastructure prior to committing.
>
> My "JPRT -testset hotspot" job went just fine and now I've submitted
> the bits for an Aurora Adhoc "RT-SVC Nightly tests" run. I'll keep
> an eye on the testing and let folks know the results.
>
> Here's my current commit message:
>
> 8130910: hsperfdata file is created in wrong directory and not cleaned 
> up if /tmp/hsperfdata_<username> has wrong permissions
> Summary: Add check for fchir() failure and disable shared PerfMemory 
> in that case.
> Reviewed-by: dcubed, simonis, gthornbr
> Contributed-by: christoph.langer at sap.com
>
> Everybody good with it (modulo any new reviewers)?
I am good with it.

Jerry
>
> Dan
>
>
> On 8/19/15 8:37 AM, Daniel D. Daugherty wrote:
>> Finally got the cycles to look at this again. Sorry for the very
>> long delay.
>>
>> More embedded below...
>>
>>
>> On 7/21/15 1:36 AM, Langer, Christoph wrote:
>>> Hi Dan,
>>>
>>> thanks for looking into that matter.
>>
>> No problem. I was one of the original reviewers of Jerry's change
>> so it only makes sense that I try to help out here. :-) Jerry
>> should also be chiming in on this thread since this his code.
>>
>>
>>> What about implementing the “fdopendir(), openat() and unlinkat()” 
>>> way of the secure file system object creation protocol already for 
>>> the platforms where those APIs are supported? And use fchdir() only 
>>> as fallback on platforms where the other APIs aren’t available yet? 
>>> But this is probably a bigger topic and should be handled in a 
>>> different change.
>>
>> That would definitely have to be examined in a different bug.
>> We're trying to keep all the UNIX-like code as similar as
>> possible so there would need to be a well defined breakage
>> to justify doing something platform specific here.
>>
>>
>>> Should you come to the final conclusion that the changes are good, 
>>> it would be great if you could sponsor it.
>>
>> Yes, I will sponsor the change. I'll also run it through our
>> internal testing infrastructure prior to committing.
>>
>> Dan
>>
>>
>>
>>>
>>> Best regards
>>> Christoph
>>>
>>>
>>>
>>>
>>> From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com]
>>> Sent: Montag, 20. Juli 2015 16:19
>>>
>>> ...
>>>
>>> On 7/17/15 4:58 PM, Volker Simonis wrote:
>>> > and I also share his doubts about changing the current working 
>>> directory.
>>> > I think this is questionable because it can have non-local side 
>>> effects
>>> > but I think this should be fixed in a follow up change.
>>>
>>> Changing the working directory can definitely have non-local side
>>> effects, but the change of directory is a necessary part of the
>>> secure file system object creation protocol. Jerry has a good
>>> comment that explains what APIs we would rather use than changing
>>> the current working directory, but those APIs don't exist on all
>>> platforms (yet).
>>>     348 // NOTE: The code below uses fchdir(), open() and unlink() 
>>> because
>>>   349 // fdopendir(), openat() and unlinkat() are not supported on all
>>>   350 // versions.  Once the support for fdopendir(), openat() and 
>>> unlinkat()
>>>   351 // is available on all supported versions the code can be changed
>>>   352 // to use these functions.
>>>   353
>>>   354 // Open the directory of the given path, validate it and set the
>>>   355 // current working directory to it.
>>>   356 // Return a DIR * of the open directory and the saved cwd fd.
>>>   357 //
>>>   358 static DIR *open_directory_secure_cwd(const char* dirname, int 
>>> *saved_cwd_fd) {
>>>
>>> The protocol is basically:
>>>
>>>    open_directory_secure_cwd()
>>>    do operations to files in the directory using relative paths
>>>    close_directory_secure_cwd()
>>>
>>> The alternative of using full paths is difficult to do safely without
>>> exposure to attacks along exposed path elements.
>>>
>>>
>>
>>
>