Bug 47645 - [40cat] SecurityException running unforked <java> with permissions="..." or failonerror="true"
[40cat] SecurityException running unforked <java> with permissions="..." or f...
Status: RESOLVED FIXED
Product: projects
Classification: Unclassified
Component: Ant
4.x
All All
: P3 (vote)
: 6.x
Assigned To: Jesse Glick
issues@projects
http://issues.apache.org/bugzilla/sho...
: RELNOTE
: 100827 (view as bug list)
Depends on: 41689
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-22 00:38 UTC by jasondonmoyer
Modified: 2007-10-30 16:57 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
test case (5.07 KB, application/octet-stream)
2004-08-24 01:35 UTC, jasondonmoyer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jasondonmoyer 2004-08-22 00:38:04 UTC
[ BUILD # : 200408191352 ]
[ JDK VERSION : J2SE 1.4.2_05 ]

I get the following output when running an ant target containing a <sequential> block which invokes several <java> subtasks with similar arguments (no forking, failonerror=true, using a valid classpathref).  This output occurs when encountering the first <java> subtask.  The same build.xml can be run successfully from the command line using the same version of ant.


C:\dev\Insight\Manager\build\build.xml:118: java.lang.SecurityException

	at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:192)

	at org.apache.tools.ant.taskdefs.Java.execute(Java.java:83)

	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)

	at org.apache.tools.ant.Task.perform(Task.java:364)

	at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:64)

	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)

	at org.apache.tools.ant.Task.perform(Task.java:364)

	at org.apache.tools.ant.Target.execute(Target.java:341)

	at org.apache.tools.ant.Target.performTasks(Target.java:369)

	at org.apache.tools.ant.Project.executeTarget(Project.java:1214)

	at org.apache.tools.ant.Project.executeTargets(Project.java:1062)

	at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:216)

	at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:230)

	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)

Caused by: java.lang.SecurityException

	at org.netbeans.TopSecurityManager.checkSetSecurityManager(TopSecurityManager.java:315)

	at org.netbeans.TopSecurityManager.checkPermission(TopSecurityManager.java:287)

	at java.lang.System.setSecurityManager0(System.java:220)

	at java.lang.System.setSecurityManager(System.java:212)

	at org.apache.tools.ant.types.Permissions.restoreSecurityManager(Permissions.java:146)

	at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:203)

	at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:130)

	at org.apache.tools.ant.taskdefs.Java.run(Java.java:705)

	at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:177)

	... 13 more

--- Nested Exception ---

java.lang.SecurityException

	at org.netbeans.TopSecurityManager.checkSetSecurityManager(TopSecurityManager.java:315)

	at org.netbeans.TopSecurityManager.checkPermission(TopSecurityManager.java:287)

	at java.lang.System.setSecurityManager0(System.java:220)

	at java.lang.System.setSecurityManager(System.java:212)

	at org.apache.tools.ant.types.Permissions.restoreSecurityManager(Permissions.java:146)

	at org.apache.tools.ant.taskdefs.ExecuteJava.run(ExecuteJava.java:203)

	at org.apache.tools.ant.taskdefs.ExecuteJava.execute(ExecuteJava.java:130)

	at org.apache.tools.ant.taskdefs.Java.run(Java.java:705)

	at org.apache.tools.ant.taskdefs.Java.executeJava(Java.java:177)

	at org.apache.tools.ant.taskdefs.Java.execute(Java.java:83)

	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)

	at org.apache.tools.ant.Task.perform(Task.java:364)

	at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:64)

	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275)

	at org.apache.tools.ant.Task.perform(Task.java:364)

	at org.apache.tools.ant.Target.execute(Target.java:341)

	at org.apache.tools.ant.Target.performTasks(Target.java:369)

	at org.apache.tools.ant.Project.executeTarget(Project.java:1214)

	at org.apache.tools.ant.Project.executeTargets(Project.java:1062)

	at org.apache.tools.ant.module.bridge.impl.BridgeImpl.run(BridgeImpl.java:216)

	at org.apache.tools.ant.module.run.TargetExecutor.run(TargetExecutor.java:230)

	at org.netbeans.core.execution.RunClassThread.run(RunClassThread.java:125)

BUILD FAILED (total time: 0 seconds)
Comment 1 Jesse Glick 2004-08-22 16:53:21 UTC
Only if you set the 'permissions' attribute, I presume.

Sorry, there is no way to fix this currently; <java fork="false"
permissions="..."> as implemented is simply incompatible with Ant
being run in a container, as it assumes it can set the security
manager for the whole VM. Would need a new API in Ant to permit a
container to manage permissions on behalf of Ant, by temporarily
registering lists of permissions with the active thread.

Ant's Permissions has methods setSecurityManager and
restoreSecurityManager, but these are inherently unsafe, as the
security manager is VM-global and Ant is generally running in only one
thread group, while other activity may be occurring in other thread
groups. (Including other Ant runs - and since Permissions does not
include checks for overlapping dynamic scopes, it is possible for
P1.sSM to run, followed by P2.sSM which remember's P1's SM, followed
by P1.rSM which restores the original SM, followed by P2.rSM which
installs P1's now-obsolete SM for the whole VM, causing who knows what
kind of damage!)

Workarounds: remove the explicit permissions, if that is safe; or run
the commands forked, if that is possible.
Comment 2 jasondonmoyer 2004-08-22 21:14:07 UTC
There are no 'permissions' attributes set for these tasks.  Just
straight java invocations of a class which generates source code based
on the arguments passed.
Comment 3 Jesse Glick 2004-08-23 21:24:48 UTC
In that case can you please attach a complete test case to reproduce
the problem, including any Ant script and any source files or data it
may need to run, and reopen? The smaller the better, but anything that
can be reproduced from scratch works.
Comment 4 jasondonmoyer 2004-08-24 01:35:13 UTC
Created attachment 17056 [details]
test case
Comment 5 jasondonmoyer 2004-08-24 01:36:24 UTC
attached reproducible test case... run default ant target from within 
netbeans, get securityException... run from commandline, builds 
successfully
Comment 6 Jesse Glick 2004-08-26 00:21:45 UTC
BTW for the future please avoid unusual packaging formats such as
RAR... I did manage to find a Linux unpacker for it that seems to
work, but ZIP is much more universal (especially in the Java world).
Comment 7 Jesse Glick 2004-08-26 00:29:44 UTC
Yes, I can reproduce with your script.

Turns out setting failonerror='true' also forces there to be a
security manager, just like setting explicit permissions. (Since it
needs to trap System.exit.)

I will make a note to file a patch for Ant, perhaps it will be
possible to get this fixed in a future Ant release.
Comment 8 Jesse Glick 2004-09-10 20:05:42 UTC
Keeping open since it may be possible to fix using a future version of
Ant, TBD.
Comment 9 Milan Kubec 2004-09-14 08:52:12 UTC
This should be mentioned in release notes that it's not possible to
run target with <java> task that has 'failonerror=true' inside IDE.
The same script runs without problems outside of IDE. There is not
workaround in IDE, user has to rewrite the script (change semantics)
or run the script  from command line.
Comment 10 Jesse Glick 2004-10-22 23:51:58 UTC
Workaround (other than setting fork="true" on <java>): create a
separate build script that forks a new copy of Ant that you point to
from a freeform project.xml, or you can even put this stuff in the
regular build script if you want. Example contents:

<macrodef name="forkant">
    <element name="args" implicit="true"/>
    <sequential>
        <java classname="org.apache.tools.ant.Main" fork="true"
failonerror="true">
            <classpath>
                <fileset dir="${ant.home}/lib">
                    <include name="*.jar"/>
                </fileset>
                <!-- Path may need tweaking on non-Sun JDKs: -->
                <fileset dir="${java.home}/../lib">
                    <include name="*.jar"/>
                </fileset>
            </classpath>
            <arg value="-emacs"/> <!-- needed for err hyperlinking -->
            <arg value="-f"/>
            <arg file="build.xml"/> <!-- or whatever it is -->
            <args/>
        </java>
    </sequential>
</macrodef>
<target name="run"> <!-- example delegating target -->
    <forkant>
        <arg value="run"/>
        <!-- can also add delegate properties, e.g.
        <arg value="-Dsomething=${something}"/>
        -->
    </forkant>
</target>

Cumbersome, and output formatting is slightly different than for in-VM
Ant, but should allow you to run those scripts which would conflict
with the IDE's runtime, without physically leaving the IDE, and while
still getting IDE error hyperlinking and so on.

Note that in-VM special tasks such as <nbbrowse> and <nbjpdastart>
cannot be placed in the delegated-to script, since that will be in
another VM; but you can keep those tasks in the initial script and
still delegate to another script in another VM for the rest of the build.
Comment 11 Jaroslav Tulach 2004-10-28 17:23:43 UTC
If there is a workaround, it is likely not P2? Downgrading to P3.
Comment 12 Jesse Glick 2005-03-29 21:44:04 UTC
Will be worse with Ant 1.7 unless addressed:

http://issues.apache.org/bugzilla/show_bug.cgi?id=33361
Comment 13 Jesse Glick 2005-03-29 22:05:56 UTC
Cf. Ant bug:

http://issues.apache.org/bugzilla/show_bug.cgi?id=34229
Comment 14 Jesse Glick 2007-04-12 18:27:15 UTC
*** Issue 100827 has been marked as a duplicate of this issue. ***
Comment 15 Jesse Glick 2007-10-30 16:57:51 UTC
NB 6.0 has a custom <java> task impl anyway (from the fix of issue #56341), so I have set this to always run with
fork="true". This prevents the SE from being thrown. It can change semantics a bit but I think in most cases people
either omitted fork="true" out of forgetfulness (false is the default for historical reasons), or were just adding it
for a minor performance optimization (skips process spawn overhead). For these cases, people should see a fix. For
people who really wanted fork="false" (typically to use <permissions>), this was never working inside NB anyway, so the
fix should make things no worse.

Checking in ForkedJavaOverride.java;
/shared/data/ccvs/repository/ant/src-bridge/org/apache/tools/ant/module/bridge/impl/ForkedJavaOverride.java,v  <-- 
ForkedJavaOverride.java
new revision: 1.4; previous revision: 1.3
done


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo