Proposed JEP: Safer Process Launch by ProcessBuilder and Runtime.exec

[Roger Riggs]

Hi Raffaello,

Runtime.exec and ProcessBuilder have been a challenge from the 
beginning, on one hand
to have a reasonably cross-platform way to invoke processes and on the 
other to accommodate
the platform differences, mostly on Windows due to the various command 
line parsing decoding of
different applications and shells.

The idea is to provide greater consistency and a clear guidance about 
how to invoke applications
while guarding against inadvertent mistakes that might refer to files or 
other applications.
Assembling command lines from individual strings is error prone and 
brittle especially
in cases where some of the arguments may be assembled from configuration 
information,
external inputs, and the container or server environment.

Given the variations, the API should provide the application enough 
control and responsibility
to customize the encoding to the target application, if it is needed, 
but handle the usual cases
so it does not require developers to hand craft for each platform and 
target application.
Ideally, the customization should be clearly visible in the API and be 
clear and easy to review and audit.

Regards, Roger


On 2/24/22 4:22 PM, Raffaello Giulietti wrote:
> Hi,
>
> on Windows, the mechanism to launch a new program is for the parent to 
> call CreateProcess(). This function accepts, among others parameters, 
> a lpApplicationName string and a lpCommandLine string. There's a 
> *single* lpCommandLine that encodes all the arguments to pass to the 
> new program.
>
> The exact encoding of the arguments in the command line is imposed by 
> how the *new* program parses (decodes) the command line to get its 
> constituent parts. There are no fixed rules on how this happens. There 
> are some more or less well documented rules for some runtimes (e.g., 
> the C/C++ runtime) or for some specific programs (e.g., cmd.exe., 
> wscript.exe). In general, however, a program can decode in any way it 
> deems useful.
>
> Because the encoding is dictated by the target program's decoding, and 
> because the latter is really arbitrary, there's no safe, universal 
> procedure to encode a list of string arguments to a single command 
> line string. It is only when the decoding rules in the target program 
> are known that encoding in the parent becomes feasible.
>
> Thus, it might be more useful on Windows platforms to avoid the API 
> points that expose List<String> or String[] for the arguments to the 
> target program and use the ones that accept a single String, instead. 
> The client of those API points would then have to deal with the 
> encoding specific for that program. This is a better match with the 
> underlying OS mechanism, namely CreateProcess(), which accepts a 
> single, already encoded string.
>
> In addition, to assist programmers unfamiliar with specific encodings, 
> widely used specific encoders (e.g., for the C/C++ runtime [1], for 
> cmd.exe, etc.) can be implemented separately.
>
>
> Greetings
> Raffaello
>
> ----
>
> [1] 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2022-February/086105.html