On Wed, 4 Aug 2021 13:35:59 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> We should not leak the handle to the jimage file (lib/modules) to childs.
>>
>> JDK-8194734 did solve this for windows. We should use FD_CLOEXEC on Posix as
>> well.
>>
>> Note that this only poses a problem when a child process is spawned off not
>> via `Runtime.exec` but via another route since the spawnhelper closes all
>> file descriptors.
>>
>> ---
>> test:
>>
>> manually verified that lib/modules now has the FD_CLOEXEC flag set.
>
> src/java.base/unix/native/libjimage/osSupport_unix.cpp line 41:
>
>> 39: */
>> 40: jint osSupport::openReadOnly(const char *path) {
>> 41: return ::open(path, O_CLOEXEC);
>
> This is okay but I think it would be useful to know why this one place needs
> O_CLOEXEC and not others.
Probably others too, if we care about inheriting read handles to child.
The background is that I am playing with a new test which checks that the VM
has no open inheritable file descriptors. It is supposed to replace some
specialized tests which are maintenance-intensive. I am still tuning the test,
since at the moment it turns out too many false positives.
Anyway, this is the very first descriptor the VM opens, therefore it triggered
my test. I thought since there is a sibling fix for windows, a similar fix for
posix would be symmetric.
If you think this is not worth fixing, or we should fix all occurrences in one
swoop, that is fine too.
-------------
PR: https://git.openjdk.java.net/jdk/pull/4991
