-
1. Re: VFS Permissions - JBMICROCONT-149
starksm64 Feb 26, 2007 12:55 PM (in response to adrian.brock)Correct. So far all priviledged blocks I have are part of the JBMICROCONT-150 subtask (VFS callers are missing privileged blocks).
-
2. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 6, 2008 12:08 PM (in response to adrian.brock)Scott, what needs to be done to get AS boot under a security manager.
Any VFS related thing?
https://jira.jboss.org/jira/browse/JBAS-4154
Or are we back to this discussion?
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=143631 -
3. Re: VFS Permissions - JBMICROCONT-149
starksm64 Nov 6, 2008 12:19 PM (in response to adrian.brock)Yes, its back to having either vfs* url handlers available to the bootstrap lib or a Policy that deals with them. Its silly that CodeSource still uses a URL rather than URI since the URL contents are never used.
-
4. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 6, 2008 12:20 PM (in response to adrian.brock)11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
That is the error I am trying to get rid of that is not allowing a boot. -
5. Re: VFS Permissions - JBMICROCONT-149
dmlloyd Nov 6, 2008 12:28 PM (in response to adrian.brock)Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.
-
6. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 6, 2008 12:37 PM (in response to adrian.brock)"anil.saldhana@jboss.com" wrote:
11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
That is the error I am trying to get rid of that is not allowing a boot.
You don't show the full stacktrace, but this is on the bootstrap thread
isn't it?
If you've correctly given all the jboss jars the AllPermission
then there shouldn't be any problem here with accessing the file system.
My guess is that you haven't given them the AllPermission because of the
code source being a vfs url. -
7. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 6, 2008 12:49 PM (in response to adrian.brock)"david.lloyd@jboss.com" wrote:
Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.
I'm not sure that would work. From my experience the URL stuff does
some funny caching?
An alternative solution is to change the way the VFSClassLoaderPolicy determines
the code source. i.e. instead of returning the vfs url we could hack it to return
a normal url.
But this would restrict codesources to be the top level url, you couldn't for
example have different permissions for subdeployments in the same deployment.
The relevant code is in VFSClassLoaderPolicy@Override protected ProtectionDomain getProtectionDomain(String className, String path) { VirtualFile clazz = findChild(path); if (clazz == null) { log.trace("Unable to determine class file for " + className); return null; } try { VirtualFile root = findRoot(path); // HERE!!!!!!!! URL codeSourceURL = root.toURL();
This could for example be replaced with something like:URL codeSourceURL = VFSUtils.getRealURLHack(root);
An alternative solution would be to allow you to specify the codeSourceURL to use
for the classloader as a parameter when you create it.
The hack could then be in the jboss deployer that creates the classloader policy
rather than forcing it on every user of VFSClassLoaderPolicy.
i.e. people that use it standalone would probably include jboss-vfs.jar
in the classpath so the urls would be parsable? -
8. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 6, 2008 12:51 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
But this would restrict codesources to be the top level url, you couldn't for
example have different permissions for subdeployments in the same deployment.
IIRC the same restriction existed in JBoss4 because file and jar
urls can't describe subdeployments properly? -
9. Re: VFS Permissions - JBMICROCONT-149
dmlloyd Nov 6, 2008 12:55 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
"david.lloyd@jboss.com" wrote:
Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.
I'm not sure that would work. From my experience the URL stuff does
some funny caching?
When you set an application URLStreamHandlerFactory, it dumps the cache - it's the one and only opportunity you get to do so as far as I know. -
10. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 6, 2008 12:56 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
"anil.saldhana@jboss.com" wrote:
11:19:11,025 ERROR [AbstractKernelController] Error installing to Create: name=AspectManager state=Configured java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses read) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:264)
That is the error I am trying to get rid of that is not allowing a boot.
You don't show the full stacktrace, but this is on the bootstrap thread
isn't it?
If you've correctly given all the jboss jars the AllPermission
then there shouldn't be any problem here with accessing the file system.
My guess is that you haven't given them the AllPermission because of the
code source being a vfs url.
Yeah, this is on bootstrap, trying to deploy aop.xml
Even with java.security.debug=all setting, I am not getting any debug info (including the protection domain that is failing). All I get is the error that I showed.
I will get back on this one. -
11. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 6, 2008 12:57 PM (in response to adrian.brock)"david.lloyd@jboss.com" wrote:
"adrian@jboss.org" wrote:
"david.lloyd@jboss.com" wrote:
Just a note that vfs* handlers in the bootstrap lib don't have to be the real handlers, they can just be do-nothing stubs, since there is the opportunity to plug in a real URLStreamHandlerFactory at a later time.
I'm not sure that would work. From my experience the URL stuff does
some funny caching?
When you set an application URLStreamHandlerFactory, it dumps the cache - it's the one and only opportunity you get to do so as far as I know.
and that's spec defined or a current implementation detail of Sun's JRE? :-) -
12. Re: VFS Permissions - JBMICROCONT-149
dmlloyd Nov 6, 2008 1:04 PM (in response to adrian.brock)I can't be 100% certain. But it seems to be implied in the JDK javadoc. They don't explicitly mention caching at all (that I can find), but they do state that the URLStreamHandlerFactory can be registered at most one time, and it will be used exclusively once it is registered; how can that be true if it maintains the cache beyond that moment in time?
-
13. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 6, 2008 1:05 PM (in response to adrian.brock)12:02:47,182 DEBUG [ServerImpl] Deploying bootstrap xml:aop.xml ... 12:02:49,414 DEBUG [Domain] org.jboss.classloading.spi.dependency.Domain@3b756456{DefaultDomain} add module VFSClassLoaderPolicyModule aop-classloader:0.0.0 12:02:50,766 DEBUG [BaseClassLoader] Created BaseClassLoader@73e04a35{aop-classloader:0.0.0$MODULE} with policy VFSClassLoaderPolicy@a281902{name=aop-classloader:0.0.0$MODULE domain=null roots=[DelegatingHandler@1317132163[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-core.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-core.jar], DelegatingHandler@778830265[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-jmx.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-jmx.jar], DelegatingHandler@887435390[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-mc.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-mc.jar], DelegatingHandler@852671315[path= context=file:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-jboss5.jar real=vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-jboss5.jar]] delegates=null exported=[META-INF.maven.org.jboss.aop.jboss-aop-asintegration-mc, META-INF, org.jboss.aop.deployers, org.jboss.aop.deployment, META-INF.maven.org.jboss.aop.jboss-aop-asintegration-core, org.jboss.aop.asintegration, org.jboss.aop.asintegration.jboss4, org.jboss.aop.asintegration.core, org.jboss.aop.domain, org.jboss.aop.classpool, org.jboss.aop.asintegration.jboss5, META-INF.maven.org.jboss.aop.jboss-aop-asintegration-jmx, ] <IMPORT-ALL>NON_EMPTY} java.security.AccessControlException: access denied (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/server/default/tmp/aopdynclasses 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.checkRead(SecurityManager.java:871) at java.io.File.exists(File.java:700) at org.jboss.aop.asintegration.core.AspectManagerServiceDelegate.create(AspectManagerServiceDelegate.java:236) at org.jboss.aop.deployers.AbstractAspectManager.create(AbstractAspectManager.java:89) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:59) at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:150) at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) at org.jboss.kernel.plugins.dependency.DispatchJoinPoint.run(DispatchJoinPoint.java:47) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:54) at org.jboss.dependency.plugins.action.SimpleControllerContextAction.secureInstallAction(SimpleControllerContextAction.java:67) at org.jboss.dependency.plugins.action.AccessControllerContextAction$1.run(AccessControllerContextAction.java:80) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.dependency.plugins.action.AccessControllerContextAction.install(AccessControllerContextAction.java:103) at org.jboss.dependency.plugins.AbstractControllerContextActions.install(AbstractControllerContextActions.java:51) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1598) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1062) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:774) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:540) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBean(AbstractKernelDeployer.java:331) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deployBeans(AbstractKernelDeployer.java:309) at org.jboss.kernel.plugins.deployment.AbstractKernelDeployer.deploy(AbstractKernelDeployer.java:130) at org.jboss.kernel.plugins.deployment.BasicKernelDeployer.deploy(BasicKernelDeployer.java:76) at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:88) at org.jboss.kernel.plugins.deployment.xml.BasicXMLDeployer.deploy(BasicXMLDeployer.java:158) at org.jboss.bootstrap.microcontainer.ServerImpl.doStart(ServerImpl.java:116) at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:399) at org.jboss.Main.boot(Main.java:209) at org.jboss.Main$1.run(Main.java:544) at java.lang.Thread.run(Thread.java:595) 12:03:08,344 DEBUG [ServerImpl] Deploying bootstrap xml:jmx.xml
Ok, that is the stack trace for the record. -
14. Re: VFS Permissions - JBMICROCONT-149
adrian.brock Nov 6, 2008 1:14 PM (in response to adrian.brock)"anil.saldhana@jboss.com" wrote:
at org.jboss.kernel.plugins.dependency.DispatchJoinPoint.run(DispatchJoinPoint.java:47) at java.security.AccessController.doPrivileged(Native Method) at org.jboss.kernel.plugins.dependency.ExecutionWrapper.execute(ExecutionWrapper.java:54)
Ok, that is the stack trace for the record.
Well actually for the record, the stacktrace before that doPrivleged is irrelevant.
What is relevant is the stacktrace when the pojo got registered (which should
be pretty similar in this case?).
In the MC we remember the AccessControlContext when you register
the pojo and restore it when processing it. This avoids you gaining additional
permissions by for example getting invoked on a different thread as your
dependencies are satisfied.