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

[Daniel D. Daugherty]

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