-
Bug
-
Resolution: Fixed
-
P4
-
None
-
b81
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8141890 | emb-9 | Daniel Daugherty | P4 | Resolved | Fixed | team |
| JDK-8149217 | 8u101 | Christoph Langer | P4 | Resolved | Fixed | b01 |
| JDK-8143159 | 8u92 | Christoph Langer | P4 | Resolved | Fixed | b01 |
| JDK-8155313 | emb-8u101 | Christoph Langer | P4 | Resolved | Fixed | b01 |
The JDK on Unix/Linux platforms will create a shared memory file for performance data, named like the process pid, in /tmp/hsperfdata_<username> directory. If that directory has wrong permissions, that is, no execute permissions (e.g. mod bits 644), the performance file will be created in the current working directory. Usually the file will be deleted when the VM ends. But in this case it will remain.
One can easily reproduce it by either deleting /tmp/hsperfdata_<username> and running a Java program with umask 133 or by first doing a chmod 644 on /tmp/hsperfdata_<username> and then running a java program. After the program has finished, a new file, named like a number, will exist in the cwd.
The problem can be easily fixed by checking the return value of the fchdir() call in open_directory_secure_cwd().
One can easily reproduce it by either deleting /tmp/hsperfdata_<username> and running a Java program with umask 133 or by first doing a chmod 644 on /tmp/hsperfdata_<username> and then running a java program. After the program has finished, a new file, named like a number, will exist in the cwd.
The problem can be easily fixed by checking the return value of the fchdir() call in open_directory_secure_cwd().
- backported by
-
JDK-8141890 hsperfdata file is created in wrong directory and not cleaned up if /tmp/hsperfdata_<username> has wrong permissions
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-