[FLINK-37666] CWE-378: Creation of Temporary File With Insecure Permissions in Temporary File Creation

[Samrat002]

What is the purpose of the change

File.createTempFile() creates temporary files with permissions determined by the OS umask, which on typical POSIX systems yields world-readable permissions (-rw-r--r--, 0644). This means any local user on the same host can read the file's contents for the lifetime of the temp file. Depending on the call site, those contents can be highly sensitive:

• YarnClusterDescriptor — serialized JobGraph and Flink configuration file
• ChangelogStreamHandleReaderWithCache — cached state/changelog data
• PackagedProgram — extracted JAR libraries

The fix replaces File.createTempFile with java.nio.file.Files.createTempFile across all affected sites. On POSIX filesystems, Files.createTempFile applies owner-only permissions (-rw-------, 0600) atomically at creation time — no group or other access, and no read-then-chmod race window.

The security guarantee is POSIX-scoped (on Windows it falls back to directory ACLs, which are per-user by default), but Flink's production targets are POSIX, so the concern is fully addressed where it matters. Using the default-attribute form of Files.createTempFile (rather than passing explicit PosixFilePermissions) is intentional: explicit POSIX attributes throw UnsupportedOperationException on non-POSIX systems, making the default form the more portable choice.

Verifying the permission

  System.out.println(Files.getPosixFilePermissions(p)); // [OWNER_READ, OWNER_WRITE]
  File f = File.createTempFile("t", null);                                                                                                                           
  System.out.println(Files.getPosixFilePermissions(f.toPath())); // [OWNER_READ, OWNER_WRITE, GROUP_READ, OTHERS_READ] 

Brief change log

• PackagedProgram.java - Replaced File.createTempFile with Files.createTempFile in createTempFile method (existing deleteOnExit() retained)
• ChangelogStreamHandleReaderWithCache.java — Replaced File.createTempFile with Files.createTempFile in downloadToCacheFile; added deleteOnExit() for correct cleanup
• StreamWindowSQLExample.java — Replaced File.createTempFile with Files.createTempFile in createTempFile (existing deleteOnExit() retained)
• YarnClusterDescriptor.java — Replaced File.createTempFile with Files.createTempFile in two locations (jobGraph temp file and Flink config temp file); added deleteOnExit() to both for correct cleanup

Verifying this change

This change is a targeted security hardening / code cleanup. The security property (file permissions) is enforced by the JDK's NIO implementation and not exercised by existing Flink unit tests. No new test coverage is added, as the correct permissions can be verified by inspecting the POSIX attributes of the created file (as shown in the example above), and the surrounding logic is unchanged. Existing tests for the affected classes continue to exercise the same code paths and confirm no behavioral regression.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): (yes / no) no
• The public API, i.e., is any changed class annotated with @Public(Evolving): (yes / no) no
• The serializers: (yes / no / don't know) no
• The runtime per-record code paths (performance sensitive): (yes / no / don't know) no
• Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: (yes / no / don't know) no
• The S3 file system connector: (yes / no / don't know) no

Documentation

• Does this pull request introduce a new feature? (yes / no) no
• If yes, how is the feature documented? (not applicable / docs / JavaDocs / not documented) N/A

---

Was generative AI tooling used to co-author this PR?

• Yes (please specify the tool below)

Generated-by: [Tool Name and Version]

[flinkbot]

CI report:

• fab41ce Azure: SUCCESS

Bot commands

The @flinkbot bot supports the following commands:

• @flinkbot run azure re-run the last Azure build

[Samrat002]

@rkhachatryan PTAL whenever time

[rkhachatryan]

Can we rather delete the file explicitly?
I'm concerned that the number of such files to delete will accumulate in a long running JVM process