On Thu, 15 Aug 2024 20:28:28 GMT, Dhamoder Nalla <dhana...@openjdk.org> wrote:
>> Use the GetTempPath2 APIs instead of the GetTempPath APIs in native code >> across the OpenJDK repository to retrieve the temporary directory path, as >> GetTempPath2 provides enhanced security. While GetTempPath may still >> function without errors, using GetTempPath2 reduces the risk of potential >> exploits for users. >> >> >> The code to dynamically load GetTempPath2 is duplicated due to the following >> reasons. I would appreciate any suggestions to remove the duplication where >> possible: >> >> 1. The changes span across four different folders—java.base, jdk.package, >> jdk.attach, and hotspot—with no shared code between them. >> 2. Some parts of the code use version A, while others use version W (ANSI >> vs. Unicode). >> 3. Some parts of the code are written in C others in C++. > > Dhamoder Nalla has updated the pull request incrementally with one additional > commit since the last revision: > > fix missing code Hi, >From the linked doc: "When calling this function from a process running as SYSTEM it will return the path C:\Windows\SystemTemp, which is inaccessible to non-SYSTEM processes. For non-SYSTEM processes, GetTempPath2 will behave the same as GetTempPath." If SYSTEM and regular user processes have a different temp path, and we change temp as it's known to the attach api, they will have a different hsperfdata_username locations. Then does the attach api only find processes that are of the same category (SYSTEM vs non-SYSTEM)? e.g. "jps" for a user does not show SYSTEM processes? SYSTEM is not the "Administrator" user, so it's not going to be a very common problem, but if a Java process run as a SYSTEM then it could be an issue (is that possible?). And if Java can't be run as a SYSTEM task, then the doc states GetTempPath2 will behave the same as GetTempPath. ------------- PR Review: https://git.openjdk.org/jdk/pull/20600#pullrequestreview-2250236104
