Review request: JDK-8012453 (process) Runtime.exec(String) fails if command contains spaces [win]

[Alexey Utkin]

Hi Martin,

On 23.04.2013 20:45, Martin Buchholz wrote:
> Random comments from a former maintainer:
>
> I was never brave enough to tackle windows argument parsing or trying 
> to change legacy behavior.
>
> I'm surprised you used LinkedList, which is almost never useful.  Why 
> not ArrayList?
Here is the parsing procedure with unpredictable number of tokens. "Add" 
operation is cheapest in the LinkedList container.

> Windows has arcane command line parsing rules, which are rather 
> difficult to get right, and I'm suspicious that you are not testing 
> for all of them (e.g. odd vs. even numbers of backslashes)
Yes, we cannot predict the Windows parsing result for arbitrary command 
line, because the Windows parsing process can involve procedure of  file 
existence checking that hard to repeat. But we cannot pass the command 
line to OS without modification due to security reasons.
As Alan wrote, we need to conserve backward compatibility for case of 
the quoted executable name (that is the only secure way to run that you 
like in legacy JDK) and  provide the allowAmbigousCommands property as a 
last resort.

Regards,
-uta

>
> Martin
>
>
> On Tue, Apr 23, 2013 at 6:22 AM, Alexey Utkin <alexey.utkin at oracle.com 
> <mailto:alexey.utkin at oracle.com>> wrote:
>
>     Bug description:
>     https://jbs.oracle.com/bugs/browse/JDK-8012453
>     http://bugs.sun.com/view_bug.do?bug_id=8012453
>
>     Here is the suggested trivial fix:
>     http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.00/
>     <http://cr.openjdk.java.net/%7Euta/openjdk-webrevs/JDK-8012453/webrev.00/>
>
>     Summary:
>     ----------------------------------
>     Summary:
>            Since the changes for JDK-8005942/JDK-8009463 that commands
>     containing spaces cannot be used with Runtime.exec(String).
>     Applications should really specify the command and its arguments
>     using the Runtime.exec methods that take an array, or
>     alternatively use ProcessBuilder as recommended since jdk1.5.
>
>     Nevertheless we would like to minimize the impact for legacy
>     Windows OS Java application. For application that works without
>     the Security Manager, the "jdk.lang.Process.allowAmbigousCommands"
>     Java property could be defined programmatically or by program
>     switch [-Djdk.lang.Process.allowAmbigousCommands]. Definition of
>     the property returns old verification procedure for program name
>     and program arguments with full risk of security vulnerabilities.
>
>     For compatibility reason the case of quoted executable name in the
>     Runtime.exec(String </j2se7/api/java/lang/String.html>) was
>     supported. If the Security Manager is installed, it is called
>     twice for this case: for space-based paring result and result of
>     extended parsing procedure that takes quotation into account. We
>     do not guaranty the backward compatibility for any call with
>     quoted executable name, but in general it works.
>
>     Regards,
>     -uta
>
>