I've put the diffs on sourceforge.
Patch #521821
Regards,
Adrian
> 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
