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

[Alan Bateman]

Alexey,

I plan to review this, just don't have time to do a detailed review 
today. At a high-level then I think the approach looks reasonable. If 
someone has gone to the trouble of quoting a program path with spaces in 
it, then the fallback should handle it. It's important that the security 
manager's checkExec is called with the new path to the program and I 
didn't see that when I skimmed over the changes.

The truly ambiguous and legacy cases is difficult but we know that there 
are still applications using these JDK1.0 area APIs. The 
allowAmbigousCommands property is probably okay as a last resort.

-Alan


On 23/04/2013 14:22, Alexey Utkin 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/
>
> 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