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

[Gerald Thornbrugh]

Hi Langer,

As Dan mentioned below I did the original change.
> 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.
I will also review your change although I am not a "Reviewer".
>
>
>> 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.
I agree with Dan, we did this sot he UNIX-like code would be similar.
>
>
>> 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
I will answer any other questions you may have about the fix.

Thanks,

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