Yes, I understand all that you have stated and I will look into doing the
things that you prescribe.
But, the last test traces that I sent show that even in trusted KART (loaded
by JWS) - EntityManager em could not be created while EntityManagerFactory
emf can be created. I could have missed the point so it certainly is okay
to tell me so. It appears to me that the failure in the last set of test
traces shows that there may be a problem when creating an EntityManager even
in JWS trusted code - KART in my case.
So, I think there are two issues. Since I do not want EntityManager nor
EntityManagerFactory creation to be located in KART - but, rather to be
located in each addon - I need to clearly understand how to set privileges
for the addons as they start dynamically. Besides, I want to start
tightening up on those "AllPermissions" and only allow specific permissions.
1) I need to learn to use doPrivilege for dynamic code.
2) Is there a problem in appclient that is responsible for the failure:
em = emf.createEntityManager();
this line of code (at kart.Main.<init>(Main.java):49) in the stack trace is
now in KART - the code that has been signed by appclient/JWS. (I had failed
to make that clear - sorry.)
3) Do you know how I can use persistence.xml from each addon jar instead of
from the substrate, KART jar? Is it possible? (That's probably more of a
Derby question? so, if you happen to know where to read or who to ask would
be great).
thanx
-----Original Message-----
From: Timothy.Quinn_at_Sun.COM [mailto:Timothy.Quinn_at_Sun.COM]
Sent: Thursday, September 14, 2006 10:57 AM
To: users_at_glassfish.dev.java.net
Subject: Re: AppClient/JWS/Derby/Security problems
Hi, again, Ray.
OK, I sort of expected that you'd say that part of the code is dynamically
loaded. That is leading to the permissions problem under Java Web Start.
Because KART is loading the add on JAR itself dynamically, and because Java
Web Start did not download it there is no opportunity for Java Web Start's
security manager to grant that code elevated permissions. The Java Web
Start model is that it - meaning Java Web Start - downloads all JARs that
are needed to run the application. It grants code in an unsigned downloaded
JAR a minimal set of permissions. It grants code in a signed downloaded JAR
full permissions if the user indicates he or she trusts the cert used to
sign the JAR.
The key point of interest here is that Java Web Start does not grant any
permissions to code it did not download, not even the minimum it would grant
an unsigned JAR that it did download. Because this separately-loaded code
is in the call stack when the TopLink logic tries to read the property, the
security manager rejects TopLink's attempt because it does not trust the
intervening code. This is even though the TopLink code itself was signed
and is itself trusted.
So this aspect, at least, is a more general Java Web Start application
design issue as opposed to something related directly to app clients or
their support via Java Web Start.
I don't know if your design and the way the persistence layer works would
permit this but here's one idea you might consider. The
java.security.AccessController.doPrivileged method allows your app to run a
block of code with elevated permissions but temporarily suspending the
requirement that all intervening code has been granted elevated permissions.
This is very useful in situations like what you've described in which
privileged code calls out to non-priv'd code which then calls back into the
priv'd code again. doPrivileged lets the trusted code do what it needs to
despite the fact that it has been called by untrusted code.
So, if you could structure your app so that code in the app client (I guess
I can call it KART) - and therefore downloaded by Java Web Start - calls the
add-on code - and then the add-on code calls back into the KART code, then
the KART code could use doPrivileged to invoke the TopLink methods so that
the TopLink code can run with the required permissions.
Obviously, one needs to be very cautious in what one codes in the
doPrivileged block because untrusted code is allowed to invoke code that
runs with elevated permissions.
This page
http://java.sun.com/j2se/1.5.0/docs/guide/security/
<
http://java.sun.com/j2se/1.5.0/docs/guide/security/> has lots of links to
useful security information. This one
http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html
<
http://java.sun.com/j2se/1.5.0/docs/guide/security/doprivileged.html> has
lots of information about doPrivileged in particular, and the "Background"
section does a much better job than I have here of describing this feature.
- Tim
Martin, Ray wrote:
KART.jar is deployed to Glassfish as an AppClient Module. There is no
enterprise archive file relative to KART. When an AppClient Module is
deployed, there are two pages in the Web Admin Console. The first page has
a check box for Java Web Start enabled. I check that box. Thereafter, the
following URL in Firefox causes KART to stand up:
http//:gateway:8080/KART?prop=DBHome=/usr/local/dbHome
I also have a JSP available from an enterprise app deployed to Glassfish.
But, this is probably a 'don't care' relative to our discussion - just
wanted to make sure.
So what is the next step? Should I send something? test something? your
wish is my command...
I reviewed the stack trace below before hitting the send button and I
thought of something else that may be relevant.
There is a web app, Addons.war, that is deployed to Glassfish. In that war
file are simply three jar files - ChatAddon2.jar, DrawingAddon.jar, and
SecurityAuditor.jar
After JWS has launched KART, the substrate, a GUI is available - the user
can select a button, "VisitAddon Store". This button points to the URL of
Addons.war in Glassfish. The resulting HTTP response is parsed and the
three jar files are shown in a Swing Listbox. The user can select an addon
one at a time.
If I select ChatAddon2 from several different computers (each from a KART
launched via JWS) then the chat GUI stands up and a chat session can occur
between the collaboration nodes of the structured overlay network. This is
working.
If I select the addon, SecurityAuditor, the GUI stands up - but, this addon
is immature and does not do much just yet (but, eventually, it will need
data persistence). This addon is working to its current level and does not
crash.
If I select the addon, DrawingAddon, then the bold lines below occur - and
crash.
What is happening is that when the user selects an addon from the list, KART
asks that addon if it has a DataAccess layer. Both ChatEditor2 and
SecurityAuditor respond with a null signifying that they do not have a
DataAccess layer. DrawingAddon responds with the name of the class that is
its DataAccess layer. KART then uses its AddonClassLoader to retrieve the
DataAccess class, in this case, DataAccessImpl, from DrawingAddon.jar not
from KART.jar. After DataAccessImpl has been instantiated, KART passes emf
(EntityManagerFactory). In the method that DataAccessImpl receives emf, it
then has the line: em = emf.createEntityManager();
We discussed that EntityManagerFactory needed to be in the main class of
KART. But, we did not discuss that EntityManager needed to be in the main
class of KART. But, I will go ahead and test passing EntityManager from
KART to the DataAccessImpl - just as easy to do - just did not happen to do
it that way.
Before sending the email, I moved: em = emf.createEntityManager(); - the
main class of KART and re-tested. The error moved for both 'appclient only'
and appclient/JWS as can be seen in the attached traces.
I would like to have EntityManager and EntityManagerFactory in my
addon.DataAccessImpl class and not in kart.Main class. Also, I would like
to utilize persistence.xml from the addon jar not the KART jar. PLEASE.
-----Original Message-----
From: Timothy.Quinn_at_Sun.COM <mailto:Timothy.Quinn_at_Sun.COM> [
mailto:Timothy.Quinn_at_Sun.COM <mailto:Timothy.Quinn_at_Sun.COM> ]
Sent: Wednesday, September 13, 2006 4:19 PM
To: users_at_glassfish.dev.java.net <mailto:users_at_glassfish.dev.java.net>
Subject: Re: AppClient/JWS/Derby/Security problems
Hi, again, Ray.
In the stack trace related to the permission problem launching via Java Web
Start (in Thread-25 as excerpted below) I suspect the error occurs because,
although the TopLink code itself has been granted elevated permissions and
would be allowed to read the property, the SecurityManager will not permit
it to do so unless all intervening methods in the call stack also have that
permission. I suspect that the kart... classes are not being granted
permissions (bolded in the stack trace).
With that in mind - and if you have already described this earlier in the
mail thread I apologize for asking again - can I ask how, physically, are
the kart.* classes made available to the client? Are they packaged in the
app client itself, or in a JAR within the containing EAR? The Java Web
Start-aware app client container (ACC) should be making sure, within the
Java Web Start security model, that adequate permissions are granted to the
code downloaded in the app client JAR. If this is not happening then we
need to find out why.
- Tim
Exception in thread "Thread-25" java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAcces
sorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstruc
torAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:494)
at java.lang.Class.newInstance0(Class.java:350)
at java.lang.Class.newInstance(Class.java:303)
at kart.Model.setDataAccessLayer(Model.java:326)
at
kart.addon.loader.AddonClassLoader.loadAddon(AddonClassLoader.java:223)
at
kart.addon.loader.AddonClassLoader.beginLoad(AddonClassLoader.java:264)
at kart.addon.loader.AddonClassLoader.start(AddonClassLoader.java:256)
at kart.Model.execAddon(Model.java:230)
at kart.KARTgui$11$1.run(KARTgui.java:592)
at java.lang.Thread.run(Thread.java:595)
Caused by: java.security.AccessControlException: access denied
(java.util.PropertyPermission toplink.validation-only read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java
:264)
at
java.security.AccessController.checkPermission(AccessController.java:427)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)
at
java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1285)
at java.lang.System.getProperty(System.java:627)
at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.getConfigPro
pertyAsStringLogDebug(EntityManagerFactoryProvider.java:295)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.isValidat
ionOnly(EntityManagerSetupImpl.java:567)
at
oracle.toplink.essentials.internal.ejb.cmp3.EntityManagerSetupImpl.shouldGet
SessionOnCreateFactory(EntityManagerSetupImpl.java:577)
at
oracle.toplink.essentials.ejb.cmp3.EntityManagerFactoryProvider.createEntity
ManagerFactory(EntityManagerFactoryProvider.java:130)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:83
)
at
javax.persistence.Persistence.createEntityManagerFactory(Persistence.java:60
)
at draw.resources.dal.DataAccessImpl.<clinit>(DataAccessImpl.java:62)
... 13 more
_____
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
<mailto:users-unsubscribe_at_glassfish.dev.java.net>
For additional commands, e-mail: users-help_at_glassfish.dev.java.net
<mailto:users-help_at_glassfish.dev.java.net>