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

Langer, Christoph christoph.langer at sap.com
Tue Jul 21 07:36:31 UTC 2015

Hi Dan,

thanks for looking into that matter.

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.

Should you come to the final conclusion that the changes are good, it would be great if you could sponsor it.

Best regards

From: Daniel D. Daugherty [mailto:daniel.daugherty at oracle.com] 
Sent: Montag, 20. Juli 2015 16:19


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

  do operations to files in the directory using relative paths

The alternative of using full paths is difficult to do safely without
exposure to attacks along exposed path elements.

More information about the hotspot-dev mailing list