Skip to main content

Problem with JavaWebStart app and security on b41

2 replies [Last post]
suttridge_farm
Offline
Joined: 2006-01-27

Hi All,

I have a Swing ad-hoc client applet (written with NetBeans 5.5 daily). WHen starting this application from JavaWebStart, the java console reports the following errors :-

Java Web Start 1.5.0_06
Using JRE version 1.5.0_06 Java HotSpot(TM) Client VM
User home directory = C:\Documents and Settings\Steve
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
m: print memory usage
o: trigger logging
p: reload proxy configuration
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
0-5: set trace level to
----------------------------------------------------
2006/03/24 09:16:47 com.sun.enterprise.appclient.MainWithModuleSupport prepareSecurity
INFO: Security Manager is ON.
2006/03/24 09:16:47 com.sun.enterprise.appclient.MainWithModuleSupport setTargetServerProperties
INFO: ACC001:Using ClientContainer file: [C:\DOCUME~1\Steve\LOCALS~1\Temp\sunacc2801.xml].
2006/03/24 09:16:48 com.sun.enterprise.appclient.MainWithModuleSupport setupIIOP
INFO: ACC014: ORB host name: [localhost]
2006/03/24 09:16:48 com.sun.enterprise.appclient.MainWithModuleSupport setupIIOP
INFO: ACC013: ORB port number: [3700]
2006/03/24 09:16:51 com.sun.enterprise.appclient.MainWithModuleSupport loadMainClientClass
INFO: ACC009: Load Application Class: [hspservertest.Main]
HSP Server Test started.
2006/03/24 09:16:51 com.sun.enterprise.appclient.MainWithModuleSupport
INFO: Application main() returned; GUI elements may be continuing to run
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers)
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkMemberAccess(Unknown Source)
at java.lang.Class.checkMemberAccess(Unknown Source)
at java.lang.Class.getDeclaredField(Unknown Source)
at org.jdesktop.layout.Baseline.isOceanTheme(Baseline.java:811)
at org.jdesktop.layout.Baseline.getComboBoxBaseline(Baseline.java:715)
at org.jdesktop.layout.Baseline.getBaseline(Baseline.java:178)
at org.jdesktop.layout.GroupLayout$ComponentSpring.getBaseline(GroupLayout.java:2202)
at org.jdesktop.layout.GroupLayout$BaselineGroup.calculateBaseline(GroupLayout.java:2021)
at org.jdesktop.layout.GroupLayout$BaselineGroup.calculateSize(GroupLayout.java:1997)
at org.jdesktop.layout.GroupLayout$Group.getPreferredSize0(GroupLayout.java:1143)
at org.jdesktop.layout.GroupLayout$Spring.getPreferredSize(GroupLayout.java:1015)
at org.jdesktop.layout.GroupLayout$Group.getSize(GroupLayout.java:1190)
at org.jdesktop.layout.GroupLayout$Group.calculateSize(GroupLayout.java:1175)
at org.jdesktop.layout.GroupLayout$Group.getPreferredSize0(GroupLayout.java:1143)
at org.jdesktop.layout.GroupLayout$Spring.getPreferredSize(GroupLayout.java:1015)
at org.jdesktop.layout.GroupLayout$Group.getSize(GroupLayout.java:1190)
at org.jdesktop.layout.GroupLayout$Group.calculateSize(GroupLayout.java:1170)
at org.jdesktop.layout.GroupLayout$Group.getPreferredSize0(GroupLayout.java:1143)
at org.jdesktop.layout.GroupLayout$Spring.getPreferredSize(GroupLayout.java:1015)
at org.jdesktop.layout.GroupLayout$Group.getSize(GroupLayout.java:1190)
at org.jdesktop.layout.GroupLayout$Group.calculateSize(GroupLayout.java:1170)
at org.jdesktop.layout.GroupLayout$Group.getPreferredSize0(GroupLayout.java:1143)
at org.jdesktop.layout.GroupLayout$Spring.getPreferredSize(GroupLayout.java:1015)
at org.jdesktop.layout.GroupLayout.resetAutopadding(GroupLayout.java:793)
at org.jdesktop.layout.GroupLayout.prepare(GroupLayout.java:808)
at org.jdesktop.layout.GroupLayout.preferredLayoutSize(GroupLayout.java:641)
at java.awt.Container.preferredSize(Unknown Source)
at java.awt.Container.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at java.awt.BorderLayout.preferredLayoutSize(Unknown Source)
at java.awt.Container.preferredSize(Unknown Source)
at java.awt.Container.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.calculateSize(Unknown Source)
at javax.swing.plaf.basic.BasicTabbedPaneUI$TabbedPaneLayout.preferredLayoutSize(Unknown Source)
at java.awt.Container.preferredSize(Unknown Source)
at java.awt.Container.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at java.awt.BorderLayout.preferredLayoutSize(Unknown Source)
at java.awt.Container.preferredSize(Unknown Source)
at java.awt.Container.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at javax.swing.JRootPane$RootLayout.preferredLayoutSize(Unknown Source)
at java.awt.Container.preferredSize(Unknown Source)
at java.awt.Container.getPreferredSize(Unknown Source)
at javax.swing.JComponent.getPreferredSize(Unknown Source)
at java.awt.BorderLayout.preferredLayoutSize(Unknown Source)
at java.awt.Container.preferredSize(Unknown Source)
at java.awt.Container.getPreferredSize(Unknown Source)
at java.awt.Window.pack(Unknown Source)
at ui.HSPTestMain.initComponents(HSPTestMain.java:313)
at ui.HSPTestMain.(HSPTestMain.java:38)
at ui.HSPTestMain$10.run(HSPTestMain.java:474)
at java.awt.event.InvocationEvent.dispatch(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(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)

Looking in the server.policy file, I see the following section which ought to provide the required security clearance :-

// Following grant block is only required for Reflection. If Reflection
// is not in use the recommendation is to remove this section.
grant {
permission java.lang.RuntimePermission "accessDeclaredMembers";
};

Is there something else that needs to be done ?

Thanks,

Steve.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tjquinn
Offline
Joined: 2005-03-30

Hi, again, Steve.

We have tightened up the security on app clients downloaded via Java Web Start - if the downloaded code is not signed. As a result in build 41 the administrator would need to take some extra steps for a client like yours to work.

Things have evolved even further since build 41. The most recent nightly builds actually make dealing with the security issues easier, in my opinion, and will probably take care of the problem you described without requiring you (as the administrator) to do any extra work. If you plan to get a recent nightly build to try your client again, I have just finished a blog entry about this topic here:

http://blogs.sun.com/roller/page/quinn?entry=signed_jars_again_app_clients

and I'd urge you to take a look. You will not have to do anything more but you should be aware of what is happening.

Here's an explanation...I hope not too long...of our thinking.

To run an app client without Java Web Start, the end-user or an administrator on the user's behalf loads some of the app server installation and also the relevant app client jar file onto the user's system. This cannot happen without the knowledge and approval - one would hope - of the end-user. With this in mind, app clients run using the [i]appclient[/i] script are granted some elevated permissions that almost all useful app clients will need in order to do their work. Granting these permissions when running the app client using [i]appclient[/i] is viewed as an acceptable risk since the app client is placed on the end-user system either by the end-user him or herself or by a trusted administrator.

It is easier - and requires no one else's involvement - to obtain app client code across the network using Java Web Start. As a result, it is also riskier.

So, by default - in B41 and earlier - app clients launched using Java Web Start received only the permissions Java Web Start grants to unsigned code - and those are very minimal indeed. To allow the app client to run under Java Web Start with higher permissions, the administrator would sign the jar file that the appserver generates during deployment and place the signed version in a known place. Then the app server's Java Web Start feature would serve that signed file, rather than the unsigned one. This would allow Java Web Start to grant the downloaded app client elevated permissions.

As I said, this situation should be much easier and is more automatic in the latest nightly builds. If you can, please try that and this problem should not recur.

suttridge_farm
Offline
Joined: 2006-01-27

Hi Tim,

Once more, thanks for the comprehensive reply. The week-end is upon me here in my timezone, so I'll be checking out a new nightly b42 sometime after Monday to try it out, after having read up from your blog.

I like the way that this issue is proceeding - it makes sense to make this whole thing simpler, yet keeping the desired levels of security in place.

I'll let you know next week if I get it working OK.

Regards,

Steve.