#838 Scripts do not work if file operations are not permitted

_FreeMind_0.9.0
open
None
7
2009-05-11
2009-05-11
No

Hello,

as default setting for groovy scripts file operations are not allowed. It prevents the scripts from being executed.

How to reproduce:

1. Go to preferences->scripting and disable "permit file operations"
2. Create a new map
3. attach a script

="new text"

to the root node
4. Try to evaluate the script

Log attached.

STDOUT: message: startup failed, General error during class generation: FreeMind Groovy Skripte sind eingeschränkt. Die folgende Datei-Operation ist nicht gegeben: Read. Sie können dies in den Einstellungen ändern.

java.lang.SecurityException: FreeMind Groovy Skripte sind eingeschränkt. Die folgende Datei-Operation ist nicht gegeben: Read. Sie können dies in den Einstellungen ändern.
at plugins.script.ScriptingSecurityManager.getException(ScriptingSecurityManager.java:153)
at plugins.script.ScriptingSecurityManager.checkRead(ScriptingSecurityManager.java:139)
at freemind.main.FreeMindSecurityManager.checkRead(FreeMindSecurityManager.java:159)
at java.io.File.exists(Unknown Source)
at java.io.Win32FileSystem.canonicalize(Unknown Source)
at java.io.File.getCanonicalPath(Unknown Source)
at sun.security.provider.PolicyFile.canonPath(Unknown Source)
at java.io.FilePermission$1.run(Unknown Source)
at java.io.FilePermission$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.io.FilePermission.init(Unknown Source)
at java.io.FilePermission.<init>(Unknown Source)
at sun.net.www.protocol.file.FileURLConnection.getPermission(Unknown Source)
at java.net.URLClassLoader.getPermissions(Unknown Source)
at java.security.SecureClassLoader.getProtectionDomain(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at groovy.lang.GroovyClassLoader.access$300(GroovyClassLoader.java:57)
at groovy.lang.GroovyClassLoader$ClassCollector.createClass(GroovyClassLoader.java:445)
at groovy.lang.GroovyClassLoader$ClassCollector.onClassNode(GroovyClassLoader.java:463)
at groovy.lang.GroovyClassLoader$ClassCollector.call(GroovyClassLoader.java:467)
at org.codehaus.groovy.control.CompilationUnit$10.call(CompilationUnit.java:701)
at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:885)
at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:436)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:277)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:572)
at groovy.lang.GroovyShell.parse(GroovyShell.java:584)
at groovy.lang.GroovyShell.parse(GroovyShell.java:564)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:542)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:518)
at plugins.script.ScriptingEngine.executeScript(ScriptingEngine.java:232)
at plugins.script.ScriptingEngine.performScriptOperation(ScriptingEngine.java:111)
at plugins.script.ScriptingEngine.performScriptOperation(ScriptingEngine.java:98)
at plugins.script.ScriptingEngine.performScriptOperation(ScriptingEngine.java:98)
at plugins.script.ScriptingEngine.startupMapHook(ScriptingEngine.java:74)
at freemind.modes.mindmapmode.MindMapController.invokeHook(MindMapController.java:1722)
at freemind.modes.mindmapmode.actions.MindMapControllerHookAction.actionPerformed(MindMapControllerHookAction.java:48)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.AbstractButton.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI.doClick(Unknown Source)
at javax.swing.plaf.basic.BasicMenuItemUI$Handler.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

1 error

Discussion

  • Dimitry Polivaev

    I add error logging to
    plugins.script.ScriptingSecurityManager.checkRead(String)

    as follows

    public void checkRead(String pFile) {
    if(mWithoutFileRestriction) return;
    System.err.print("read access to " + pFile + " denied");
    throw getException(PERM_GROUP_FILE, PERM_Read);
    }

    I get log attached as modified-log.0

     
  • Dimitry Polivaev

    modified-log.0

     
  • Daniel Polansky

    Daniel Polansky - 2010-08-23

    I confirm the bug or issue in FreeMind 0.9.0 RC7; it is probably there also in RC9. Even a simple script such as '="Hello"' fails unless file operations are permitted for scripts.

    A workaround for the user is to run a script two times; the failure occurs only the first time a script is run. This workaround is barely acceptable, if at all. It seems that the only practical thing the user can do is to allow file operations in the preferences, in the section "Scripting". This reduces the security of scripting a bit, though. --Dan

     
  • Daniel Polansky

    Daniel Polansky - 2010-11-08

    I have forgotten. My testing environment right now: FreeMind 0.9.0 RC10, Java version "1.6.0_21",
    Windows Vista. It could be that the problem is specific to Windows. --Dan

     
  • Daniel Polansky

    Daniel Polansky - 2010-11-30

    In 0.9.0 RC11, an attempt has been made to fix the problem. But the problem persists, albeit in a slightly different form.

    I have a mind map with a script '="hello"'.

    When I press Alt + F8 the first time after loading the mind map, the script gets correctly executed: the text of the node with the script gets overwritten with "hello". This is an improvement over 0.9.0 RC10.

    Then I rewrite the text of the node with "world", to be able to see the effect of the script again.

    Then I press Alt + F8 again, and the script does nothing; in addition, I see the hourglass cursor signifying waiting, as if the operation were still in progress.

    When I repeatedly press Alt + F8, I get the same result: nothing happens.

    Then, I cannot close FreeMind normally and have to end it using the task manager instead, which means something got quite wrong.

    I emphasize that I am on Windows Vista.

    --Dan

     
  • Daniel Polansky

    Daniel Polansky - 2010-11-30

    I get the undesirable behavior described with 0.9.0 RC11 removed by performing the following change in ScriptingEngine.executeScript method:

    // setting the same security manager the second time causes it to be
    // removed.
    //securityManager.setFinalSecurityManager(scriptingSecurityManager); // Commented out. --Dan
    securityManager.setFinalSecurityManager(null); // Inserted: be explicit about setting it to null. --Dan

    At that location, the security manager should be disabled; if it is not, it causes problems with loading of some classes later. Setting an object two times to disable something seems like a bug-prone idea. I am setting the final security manager as null, as that is the intended effect. I am not the author of the code, so I am not sure whether it matches the intention.

    As regards the method securityManager.setFinalSecurityManager, I do not understand why it is implemented the way it is:

    public void setFinalSecurityManager(SecurityManager pFinalSecurityManager) {
    if(pFinalSecurityManager == mFinalSecurityManager) {
    mFinalSecurityManager = null;
    return;
    }
    if(mFinalSecurityManager != null) {
    throw new SecurityException("There is a SecurityManager installed already.");
    }
    mFinalSecurityManager = pFinalSecurityManager;
    }

    I would implement the method as follows:

    public void setFinalSecurityManager(SecurityManager pFinalSecurityManager) {
    mFinalSecurityManager = pFinalSecurityManager;
    }

    The method should not worry about whether there is already a security manager set. When the caller wants to get the security manager removed, the caller should be very explicit about it, by passing "null".

    --Dan

     
  • Daniel Polansky

    Daniel Polansky - 2010-12-01

    Further comment to my previous comment: It seems that the thing with setting the security manager two times to get it removed is intentional; there is a note to that effect at the top of FreeMindSecurityManager class.

    The key thing is that, after the recent bug fix, the security manager is being removed twice (as it should not): once in the method "evaluate", and once before the line "System.setOut(oldOut)". It seems that it should suffice that the line "securityManager.setFinalSecurityManager(scriptingSecurityManager);" before "System.setOut(oldOut)" is commented out.

    CVS:
    http://freemind.cvs.sourceforge.net/viewvc/freemind/freemind/plugins/script/ScriptingEngine.java?view=log

    --Dan

     
  • Daniel Polansky

    Daniel Polansky - 2010-12-05

    Fixed in 0.9.0 RC12. --Dan

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks