-
45. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 10, 2008 11:41 AM (in response to adrian.brock)"anil.saldhana@jboss.com" wrote:
Adrian, I know you disagree. But I do not see creating a vfs policy implementation before AS5GA.
I don't disagree. I'm just saying the correct mapping should be done by the vfs layer.
The experimental FileCodeSourceGenerator shows that trying to do it yourself
leads to mistakes and the alternative of having the user specify
them in some configuration file is an admin nightmare and also bound to lead to errors.
The way I see it, is that there are three changes required.
1) The ability to map a vfs url to a real (top level) url
2) Implementation of a VFSPermission that also implies the real url permission
(e.g. FilePermission for vfsfile:)
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.
If you use the security.xml bootstrap file then you can use 3(i) in your java.policy
file, otherwise you need 3(ii) unless somebody makes the vfs url handlers
available to the JDK policy class.
If you use 3(ii) then you can't specify the permissions for subdeployments
seperately from the top level deployment (just like JBoss4 couldn't). -
46. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 10, 2008 11:48 AM (in response to adrian.brock)"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). -
47. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 10, 2008 11:50 AM (in response to adrian.brock)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. :) -
48. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 10, 2008 12:42 PM (in response to adrian.brock)"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
We got JNDIPermissions from Scott recently. I think the VFSPermission should follow this format.
It is not clear how to configure the VFSClassLoaderPolicy. Is it via the classloader-system or the class loading? -
49. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 10, 2008 12:53 PM (in response to adrian.brock)"anil.saldhana@jboss.com" wrote:
It is not clear how to configure the VFSClassLoaderPolicy. Is it via the classloader-system or the class loading?
ClassLoadingMetaData.
Although being able to specify which url type to use for
the codesource somewhere once would make it easier.
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 -
50. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 10, 2008 1:04 PM (in response to adrian.brock)"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
We can do that. It essentially boils down to a temporary state (with usage of real urls) to get past the classloading bootstrap.
Do you see any other issues post security.xml bootstrap?
I think the security.xml step would need to replace the protection domain of previously added real vfs codesource. Is that consistent with your thinking? -
51. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 10, 2008 1:07 PM (in response to adrian.brock)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. -
52. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 10, 2008 1:18 PM (in response to adrian.brock)"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). -
53. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 10, 2008 1:24 PM (in response to adrian.brock)"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).
Sorry for having misunderstood. It made sense now. -
54. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 10, 2008 1:54 PM (in response to adrian.brock)The alternate approach still has the disadvantage of being late with security policy enforcement.
-
55. Re: VFS Permissions - JBMICROCONT-149
dmlloyd Nov 10, 2008 1:57 PM (in response to adrian.brock)Sorry if this is an ignorant question but - won't most (all?) of the early-boot JARs just get AllPermission anyway?
-
56. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 10, 2008 2:02 PM (in response to adrian.brock)"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?
Alternate approach of security.xml, the security manager gets installed in the stage after classloading.xml has been bootstrapped. So initialize.xml, classloading.xml went through an open door. That is what I am enquiring about.
For VFS, it depends on the VFSURLConnection.
https://jira.jboss.org/jira/browse/JBVFS-71 -
57. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 11, 2008 2:27 AM (in response to adrian.brock)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
http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/resources/securitymgr/server.policy
Basically the VFSUtils.getRealURL(vfsURL) returns the jar url or file url depending on whether the vfs protocol is "vfszip" or "vfsfile".
Please comment on this approach. -
58. Re: VFS Permissions - JBMICROCONT-149
alesj Nov 11, 2008 4:13 AM (in response to adrian.brock)"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.
Should I hold off VFS 2.0.0.GA until these features get into VFS? -
59. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 11, 2008 4:14 AM (in response to adrian.brock)"anil.saldhana@jboss.com" wrote:
"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?
Alternate approach of security.xml, the security manager gets installed in the stage after classloading.xml has been bootstrapped. So initialize.xml, classloading.xml went through an open door. That is what I am enquiring about.
But typically they will run under AllPermission anyway.
The only reasons I put security.xml after classloader.xml is because
1) There maybe permission classes in the classloader setup by classloader.xml
that need to be loadable.
2) In future we would probably load our own policy implementation
which would be defined in the secutiry.xml classloader rather than
being hardwired in our bootstrap.