This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 19358 - java.security.AccessControlException when custom property editor uses JFileChooser
Summary: java.security.AccessControlException when custom property editor uses JFileCh...
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: All All
: P3 blocker (vote)
Assignee: phamernik
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-01-11 16:15 UTC by Russell East
Modified: 2008-12-23 14:30 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
a JAR containing source code for the sample bean (8.14 KB, application/octet-stream)
2002-01-11 16:20 UTC, Russell East
Details
a JAR containing the bean's compiled classes, icon and the manifest (7.40 KB, application/octet-stream)
2002-01-11 16:22 UTC, Russell East
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Russell East 2002-01-11 16:15:44 UTC
I have:
 - built a simple bean with a single String property,
 - added BeanInfo for the bean,
 - setup a property editor for the single property,
 - setup a custom property editor consisting of a JPanel
   that contains a TextField and a JButton - the JTextField
   allows an end-user to type in the value of the property
   string - clicking the JButton opens a JFileChooser so
   that end-user can point to a file and click after which
   the JTextField is populated with the file pathname, and
 - created a jar that has these components together
   with a manifest that identifies the bean

I can then create a sample JFrame application wherein I:
 - add the above sample bean into the component palette using Tools/NewJavaBean
 - drag-n-drop the bean into the JFrame
 - select the bean in the form,
 - select the single property in the Properties dialog
 - select the property customizer

This opens a dialog containing my custom property editor, and looks correct!

What I then should be able to do is:
 - either enter text into the JTextField,  and/or
 - click the JButton to open the JFileChooser

The JTextField works fine.  But when I click the JButton, I immediately get the
following exception:
  java.security.AccessControlException: access denied (java.io.FilePermission
{my home directory} write)
(where "{my home directory}" is the path to my system home directory.
I have tried messing with the JDK security options to try to work around this
issue without success.

In any case, I think this message is bogus, because I have found a really ugly
workaround that does not involve security at all.  Here is the workaround:
 - after receiving the above message, I close the error message dialog box,
 - I enter text into the JTextField and press OK in the property editor dialog
   (this ensures that code is written into the sample application)
 - I then save all files in the project
 - I then select Project/ProjectManager and open the Default project
 - after the Default project opens, I once again select Project/ProjectManager
   and re-open the sample application project
 - I then select the bean, and choose to customize the property
 - the property editor dialog opens once more
 - this time, when I click the button, it opens the JFileChooser no problem

But, if I drag the bean into the application form once more - add another
instance of the bean, I experience exactly the same problem with the JButton for
the new instance, even though the first instance has no problem.  Really weird!
Comment 1 Russell East 2002-01-11 16:20:32 UTC
Created attachment 4118 [details]
a JAR containing source code for the sample bean
Comment 2 Russell East 2002-01-11 16:22:39 UTC
Created attachment 4119 [details]
a JAR containing the bean's compiled classes, icon and the manifest
Comment 3 David Strupl 2002-01-11 17:51:15 UTC
Hello,
I have tried your example and found this:

The problem occurs only in case you have the classes compiled in the
IDE before you install your JavaBean. So the problem go away if you
just install the resulting jar and you don't have the sources mounted
in the IDE. There is probably a problem in the classloader somewhere.
but it needs further investigation.

Making it P3 since there is a workaround that is not that complicated.
Side note: I have just grabbed your .jar file and tried to install the
 bean - there were no problems. I played with it in form editor -
still no problems. After a while I tried to also look at the sources
and compiled them - and voila the problem started to occur. So no
sources no problem ;-0
Comment 4 Russell East 2002-01-11 20:55:05 UTC
I tried your workaround, but I still see the problem.  I'm not totally
sure that I was able to "unmount the sources" exactly.

I basically have two projects - SampleBean defines the bean and jar
stuff, and, TestSampleBean holds the end-user application that uses
the SampleBean.

I didn't want to delete SampleBean, so all I did was go into the
project, select FileSystems within the Explorer, and unmount the local
directory whre the code resides.  Was that sufficient?

I also stopped then re-started NetBeans.  Neither of these made any
difference.  I still get the SecurityAccessException first up.
Comment 5 Russell East 2002-01-11 21:50:49 UTC
Ok, just to be a bit more specific, here's what I did to check out
your workaround.  Btw, my develop system is Linux, just to help with
the following:

  1) I quit NetBeans
  2) I removed $HOME/nbuser33 completely
  3) I removed {installDir}/netbeans completely
  4) I restored NetBeans by un-taring the distro
  5) I restarted NetBeans - completely fresh version
  6) I created a new JFrame app
  7) I remembered I'd kept the jar file inside nbuser33 (oops)
  8) I downloaded the sample.jar from this web page (yay!)
  9) I used Tools/InstallNewJavaBeans to add my bean to the Palette
 10) I added an instance of the sample bean to my JFrame app
 11) I selected the bean, went into properties,
 12) I opened the custom proeprty editor, clicked the JButton

- SecurityAccessException still  :-(
Comment 6 David Strupl 2002-01-14 08:45:50 UTC
I did exactly the 12 steps you put here and it did not occur. But it
did occur if I have the sources mounted and compiled them. The
unmounting procedure (Filesystems tab, right click the local file
system, unmount) was correct. The only problem is that after
unmounting the sources you have to restart the IDE (this at least
worked for me).

Anyway are you saying that you can see the exception even in case in
which your filesystem tab does not contain the sources and you have
just started the IDE? I also assume you don't have the sources for the
editor in the same directory as your fresh JFrame app. Simply put are
you saying that the IDE can see only the jar from "Install new
JavaBean" and not the original sources/classes?

If you still have problems please zip and attach your nbuser33/system
directory to this bug (i hope it does not contain any secret
information you cannot share with us). Also please attach your policy
files - $JAVA_HOME/jre/lib/security/java.policy,
$NETBEANS_HOME/bin/ide.policy. Those files should not differ but I
might have modified my copies and would like to be sure we use the same.

Thanks for your time (and patience with me).
Comment 7 Tomas Pavek 2002-01-14 11:17:12 UTC
Now I probably know how this happens...
There are basically two problems:
- a ClassLoader problem with instance support,
- a strange behaviour in EditorSupport stuff in org.openide.text

1) The class loader problem - classes loaded by InstanceSupport (for 
InstanceDataObjects) are loaded by a custom class loader 
(NbClassLoader) granting only read only access permissions. So 
classes added from palette to form don't have write permission. 
However the same classes loaded by form editor during form opening 
using TopManager.currentClassLoader have write permission - that's 
why the mentioned "workaround" works.

2) The second part of the problem is the question why the custom user 
class would need the write permission. It is needed due to the 
behaviour of EditorSupport I don't understand. Briefly - when doing 
some change in custom property editor, the change is propagated to 
form editor which regenerates the code - so replaces the guarded 
section in the java document. But this leads in the end to asking 
wheteher the java file is read only, which requires the write 
permission. I don't know why this read-only check on file is done 
with each change to the document. This did not happen in 3.2.1 (even 
for the first change). I'm attaching the stack trace:

java.security.AccessControlException: access denied
(java.io.FilePermission
C:\BuildDev_Work\settings\sampledir\Fr1.java write)
at java.security.AccessControlContext.checkPermission
   (AccessControlContext.java:272)
at java.security.AccessController.checkPermission
   (AccessController.java:399)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:545)
at org.netbeans.core.execution.TopSecurityManager.checkPermission
   (TopSecurityManager.java:243)
at java.lang.SecurityManager.checkWrite(SecurityManager.java:978)
at org.netbeans.core.execution.TopSecurityManager.checkWrite
   (TopSecurityManager.java:186)
at java.io.File.canWrite(File.java:527)
at org.openide.filesystems.LocalFileSystem.readOnly
   (LocalFileSystem.java:401)
at org.openide.filesystems.LocalFileSystem$Impl.readOnly
   (LocalFileSystem.java:691)
at org.openide.filesystems.AbstractFileObject.isReadOnly
   (AbstractFileObject.java:134)
at org.openide.text.DataEditorSupport.messageName
   (DataEditorSupport.java:152)
at org.openide.text.EditorSupport$Del.superMessageName
   (EditorSupport.java:673)
at org.openide.text.EditorSupport.messageName(EditorSupport.java:147)
at org.openide.text.EditorSupport$Del.messageName
   (EditorSupport.java:648)
at org.openide.text.CloneableEditor.updateName
   (CloneableEditor.java:496)
at org.openide.text.CloneableEditorSupport.updateTitles
   (CloneableEditorSupport.java:1210)
at org.openide.text.EditorSupport$Del.superUpdateTitles
   (EditorSupport.java:689)
at org.openide.text.EditorSupport.updateTitles(EditorSupport.java:162)
at org.openide.text.EditorSupport$Del.updateTitles
   (EditorSupport.java:664)
at org.openide.text.CloneableEditorSupport.notifyModified
   (CloneableEditorSupport.java:930)
at org.openide.text.EditorSupport$Del.superNotifyModified
   (EditorSupport.java:628)
at org.openide.text.EditorSupport.notifyModified
   (EditorSupport.java:443)
at org.netbeans.modules.java.JavaEditor.notifyModified
   (JavaEditor.java:535)
at org.openide.text.EditorSupport$Del.notifyModified
   (EditorSupport.java:616)
at org.openide.text.CloneableEditorSupport$Listener.removeUpdate
   (CloneableEditorSupport.java:1348)
at javax.swing.text.AbstractDocument.fireRemoveUpdate
   (AbstractDocument.java:228)
at org.netbeans.editor.BaseDocument.fireRemoveUpdate
   (BaseDocument.java:895)
at org.netbeans.editor.BaseDocumentEvent.undo
   (BaseDocumentEvent.java:198)
at org.netbeans.editor.GuardedDocumentEvent.undo
   (GuardedDocumentEvent.java:41)
at javax.swing.undo.CompoundEdit.undo(CompoundEdit.java:48)
at org.netbeans.editor.BaseDocument$AtomicCompoundEdit.undo
   (BaseDocument.java:1269)
at org.netbeans.editor.BaseDocument.breakAtomicLock
   (BaseDocument.java:959)
at org.netbeans.editor.BaseDocument.runAtomicAsUser
   (BaseDocument.java:780)
at org.netbeans.editor.GuardedDocument.runAtomic
   (GuardedDocument.java:217)
at org.openide.text.NbDocument.runAtomic(NbDocument.java:295)
at org.openide.text.PositionBounds.setText(PositionBounds.java:108)
at org.netbeans.modules.java.JavaEditor$GuardedSection.setText
   (JavaEditor.java:1448)
at org.netbeans.modules.java.JavaEditor$SimpleSection.setText
   (JavaEditor.java:1536)
...
< snip >
...
at zkx.ZkBeanX1BeanInfo$ZkCustomizer.access$001
   (ZkBeanX1BeanInfo.java:374)
at zkx.ZkBeanX1BeanInfo$1.actionPerformed(ZkBeanX1BeanInfo.java:390)
at javax.swing.AbstractButton.fireActionPerformed
(AbstractButton.java:1450)
...

You see the custom user class with read permission on the call stack 
leading into AccessControlException because write permission is 
required.


I have already workarounded both problems, so it should work in 
3.3.1, however I would like if somebody looked at 1) and 2) whether 
the described behaviour is really intended and correct.
Comment 8 David Strupl 2002-01-14 16:21:44 UTC
I have good news for Russel: the bug seems fixed both in [dev] and
[release33]. So the fixed version should appear next week as NetBeans
3.3.1 RC1. Please check this version and report back if the problem
persist. According to Tomas' suggestion I am reassigning to a person
who migth know more about InstanceSupport and about the classloader it
uses for laoding the instances.
For Petr: if everything is Ok I recommend to mark this issue as fixed.
It at least works for me for [dev] and [release33] build.
Comment 9 Russell East 2002-01-14 18:20:00 UTC
Sounds good, I'll look for the soluton next week.

Is it likely that all restrictions on custom property editors will be
dropped, or will the soluton be simply to add read/write file access?  

Seems to me that a custom editor should be trusted implicitly, since
the end-user has already chosen to install the 3rd party components.
Comment 10 peterp 2002-01-18 12:19:17 UTC
*** [FFJ CUSTBUG] bug was entered by external partner ***
Comment 11 phamernik 2002-01-22 14:44:55 UTC
Fixed in form editor.
Comment 12 pzajac 2003-08-14 17:41:51 UTC
verified
Comment 13 Quality Engineering 2008-12-23 14:30:58 UTC
This issue had *2 votes* before move to platform component