Thanks for clarification, Alan!
A part of the fix was not covered by summary, but need to be mentioned.
I changed in the ProcessBuilder class to restore the compatibility with
Java documentation. In accordance with spec, the
IllegalArgumentException exception could not be thrown from the start
method. I made it a cause for declared IOException.
On 23.04.2013 23:39, Alan Bateman wrote:
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.
You are right. The call was lost in the latest refactoring process for
Java property.
Thanks for your attention. The test was extended to cover the case.
New version:
http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-8012453/webrev.01/
Lines 381-382 in ProcessImpl.java file are responsible for the second
call to Security Manager.
The call with [".\Program Files\doNot.cmd" arg] param does not pass the
second Security Manager verification in the ExecCommand.java test.
-uta
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
