JBossDeveloper

Adrian, I agree with whatever you said. I do not like the security.xml approach because you have not shielded the initialize.xml and classloading.xml bootstrap. Where are the controls for these? The default java.policy? I think it does not kick in because we have not enabled the SM.

Please correct me if I missed something. :)

"adrian@jboss.org" wrote:

"adrian@jboss.org" wrote:

1) The ability to map a vfs url to a real (top level) url

This requires something in the VFS, my suggestion was to add
VFSUtils.getRealURL(vfsFile);

2) Implementation of a VFSPermission that also implies the real url permission
(e.g. FilePermission for vfsfile:)

This is also in the VFS, in the url handlers.

3) The option when you create a vfs classloader to specify whether to use
(i) the vfs url or (ii) the real url as the codesource.
Either way, we should include the VFSPermission in the ProtectionDomain
of the class defined by the VFSClassLoaderPolicy.

This is in the VFSClassLoaderPolicy and it is a simple boolean
to control which codeSourceURL to use.
It also requires adding root.toURL().openConnection().getPermission()
to the permissions of the protection domain (assuming it is not the
default AllPermission like it currently is now for vfs urls).

https://jira.jboss.org/jira/browse/JBNAME-8

"adrian@jboss.org" wrote:

We could try to make this intelligent? i.e. use the real url by default
but then switch it if you configure conf/security.xml

Additionally we can retain security.xml enabled. We should make it do the replacement work only if JBoss was started with a SM.

I mean your original proposal of injecting the security manager in the security.xml needs to be removed and the replacement of protectiondomain becomes its objective.

"adrian@jboss.org" wrote:

"anil.saldhana@jboss.com" wrote:
Additionally we can retain security.xml enabled. We should make it do the replacement work only if JBoss was started with a SM.

I mean your original proposal of injecting the security manager in the security.xml needs to be removed and the replacement of protectiondomain becomes its objective.

I'm sorry you've lost me again.
conf/security.xml is an alternate to having to use the system properties.

I created it because it is easier to configure than having to remember
to specify system properties on the command line and avoids the vfs url
parsing problem.

Going forward conf/security.xml is what we want since it enables configuration
(including our own security policy) from the profile service and therefore
the management console.

I've got no idea what you mean about replacing the protection domain?
The protection domain is loaded from the security policy using the codesource url.

The discussion above is about which codesource to use
and automatically augmenting the returned permission collection
with read access for the VFS, file, etc. from where we loaded the class
(which can be different to the logical codesource - e.g. a copy of a nested jar into temp).

The alternate approach still has the disadvantage of being late with security policy enforcement.

Sorry if this is an ignorant question but - won't most (all?) of the early-boot JARs just get AllPermission anyway?

"david.lloyd@jboss.com" wrote:
Sorry if this is an ignorant question but - won't most (all?) of the early-boot JARs just get AllPermission anyway?

Adrian, we have an opportunity to use the jar url format to specify the permissions instead of the vfs url format. I know this is not ideal but I have tested the following:

grant codeBase "jar:file:${jboss.server.home.dir}/deploy/jms-ra.rar!/jms-ra.jar/-" {
 permission java.lang.RuntimePermission "setContextClassLoader";
 permission org.jboss.naming.JndiPermission "<<ALL BINDINGS>>","lookup";
 permission java.io.FilePermission "${jboss.home.dir}/lib/jboss-aop.jar", "read";
 permission javax.management.MBeanPermission "*", "getAttribute,invoke,setAttribute";
};

grant codeBase "jar:file:${jboss.server.home.dir}/deploy/jbossweb.sar!/jstl.jar/-" {
 permission java.security.AllPermission;
};

etc

"adrian@jboss.org" wrote:

"adrian@jboss.org" wrote:

1) The ability to map a vfs url to a real (top level) url

This requires something in the VFS, my suggestion was to add
VFSUtils.getRealURL(vfsFile);

2) Implementation of a VFSPermission that also implies the real url permission
(e.g. FilePermission for vfsfile:)

This is also in the VFS, in the url handlers.