The patch mentioned doesn't have a serious
performance overhead running without a SecurityManager.
The times for running the testsuite on my laptop are:
Before 465 secs
After 480 secs
But I think I've found a problem.
When I tested this before, I just got the system
to boot and deployed an jar that tried to do file
access.
This time I ran the testsuite (to get performance figures) and I hit a problem
straight-away.
The BmpUnitTestCase does a lookup of the datasource in
ENC. This fails, ENCFactory tries to get the context
class loader, but it is still running the ejb's
permissions.
I went back to try it on 2.4.4.
This time I used the tomcat-test.ear deployment.
The example fails on marshalledObject.get()
It tries to load the bean classes in the servlet
but it isn't allowed to read from the nested jar.
URLClassLoader hasn't given it the permissions.
Shouldn't there be some doPrivileged blocks in
there somewhere?
This might just be my lack of understanding or
misconfiguration?
Regards,
Adrian
> Hi Scott,
>
> I've got a patch that stores the original deployment
> url in the UnifiedClassLoader.
> If it's a subpackage it stores the topmost parent
> from DeploymentInfo.
>
> Then in UnifiedClassLoader it does
>
> protected PermissionsCollection
> getPermissions(CodeSource cs)
> {
> CodeSource origCS = new CodeSource(origURL,
> , cs.getCertificates());
> super.getPermissions(origCS);
> }
>
> I'm not sure about the performance impact of this
> code,
> especially on java 1.4
>
> I'm don't know whether the certificates part works?
>
> I haven't tested it with current CVS.
> It didn't work with the Jetty MBeans. They didn't
> get
> a UnifiedClassLoader, but that is easy to fix.
>
> One annoying feature of the new single deploy/
> directory will be you can't do
>
> grant codeBase "file:/$(jboss.home}/bin/*" {
> permission java.security.AllPermission;
> }
> grant codeBase "file:/$(jboss.home}/lib/*" {
> permission java.security.AllPermission;
> }
> grant codeBase "file:/$(jboss.home}/lib/ext/*" {
> permission java.security.AllPermission;
> }
> grant codeBase "file:/$(jboss.home}/deploy/lib/*" {
> permission java.security.AllPermission;
> }
> grant {
> permission java.util.PropertyPermission "*",
> ", "read";
> permission java.lang.RuntimePermission
> on "queuePrintJob";
> permission java.net.SocketPermission "*",
> ", "connect";
> }
>
> To get the specs recommendation.
> You have to list every sar in deploy/
>
> Regards,
> Adrian
>
> > The only simple solution I can see to the local
> > tmp/deploy
> > copy name problem as it relates to being able to
> > specify
> > Java2 codebase permissions is to replicate the
> > original
> > url path under the tmp/deploy directory. So:
> >
> > path1/lib =>
> > ${jboss.home}/tmp/deploy/path1/lib
> > path1/lib/ext =>
> > ${jboss.home}/tmp/deploy/path1/lib/ext
> > path2/deploy =>
> > ${jboss.home}/tmp/deploy/path2/deploy
> > path3/deploy =>
> > ${jboss.home}/tmp/deploy/path3/deploy
> > httpPath1/lib/a.jar =>
> > ${jboss.home}/tmp/deploy/http/host/path1/lib
> > httpPath1/lib/ext/b.jar =>
> > ${jboss.home}/tmp/deploy/http/host/path1/lib/ext
> >
> > Which allows for a simple transformation from the
> > original permission
> > specification to the reployment location:
> >
> > grant codeBase "file:/path1/lib/ext/*" {
> > permission java.lang.RuntimePermission
> > on "setPrincipalInfo";
> > };
> >
> > becomes:
> >
> > grant codeBase
> > "file:/${jboss.home}/tmp/deploy/path1/lib/ext/*" {
> > permission java.lang.RuntimePermission
> > on "setPrincipalInfo";
> > };
> >
> > grant codeBase "http://installhost/path1/lib/ext/*";
> {
> > permission java.lang.RuntimePermission
> > on "setPrincipalInfo";
> > };
> >
> > becomes:
> >
> > grant codeBase
> >
> "file:/${jboss.home}/tmp/deploy/http/installhost/path1
>
> > lib/ext/*" {
> > permission java.lang.RuntimePermission
> > on "setPrincipalInfo";
> > };
> >
> > since the PolicyFile implementation does allow
> > property references.
> > You won't be able to assign permissions to
> individual
> > jars or
> > subcomponents of ears, wars, sars, etc., but I
> think
> > we can live
> > with that. Any better ideas?
> >
> > xxxxxxxxxxxxxxxxxxxxxxxx
> > Scott Stark
> > Chief Technology Officer
> > JBoss Group, LLC
> > xxxxxxxxxxxxxxxxxxxxxxxx
> >
> >
> > _______________________________________________
> > Jboss-development mailing list
> > [EMAIL PROTECTED]
> >
> https://lists.sourceforge.net/lists/listinfo/jboss-dev
>
> > lopment
>
_________________________________________________________
View thread online: http://main.jboss.org/thread.jsp?forum=66&thread=9441
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
