-
90. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 11, 2008 5:23 PM (in response to adrian.brock)DML, we install the
http://anonsvn.jboss.org/repos/common/common-core/trunk/src/main/java/org/jboss/net/protocol/URLStreamHandlerFactory.java
in AbstractServerImpl
http://anonsvn.jboss.org/repos/jbossas/trunk/bootstrap/src/main/org/jboss/bootstrap/AbstractServerImpl.java
right in the server bootstrap in Main.java
This is before the protocol handlers sys prop is read. -
91. Re: VFS Permissions - JBMICROCONT-149
starksm64 Nov 11, 2008 6:17 PM (in response to adrian.brock)Then dropping stub handlers in the server endorsed lib seems like the best approach to me. Can someone try it out? I have to actually get some profileservice work done today !
-
92. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 11, 2008 7:34 PM (in response to adrian.brock)We used some stub handlers in the Main project with "org.jboss.booturl.xxx" and with the following run command(notice the system property to set the handlers)
-Djava.security.manager -Djava.security.policy==/home/anil/jboss-5.0/jboss-head/testsuite/output/resources/securitymgr/server.policy -Djava.security.debug=access,failure,policy -Djava.protocol.handler.pkgs=org.jboss.booturl
The following vfs entry in the policy file:grant codeBase "vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-core.jar" { permission java.security.AllPermission; };
From the security manager logs:policy: policy: Adding policy entry: policy: signedBy null policy: codeBase vfszip:/home/anil/jboss-5.0/jboss-head/build/output/jboss-5.0.0.GA/lib/jboss-aop-asintegration-core.jar access: access allowed (java.util.PropertyPermission java.protocol.handler.pkgsread) access: access allowed (java.lang.reflect.ReflectPermission suppressAccessChecks) policy: (java.security.AllPermission <all permissions> <all actions>) policy: policy: Adding policy entry: policy: signedBy null policy: codeBase file:/home/anil/jboss-5.0/jboss-head/testsuite/output/lib/securitymgr/- access: access allowed (java.io.FilePermission /home/anil/jboss-5.0/jboss-head/testsuite/output/lib/securitymgr/- read) policy: (java.util.PropertyPermission * read) policy: (java.io.FilePermission <<ALL FILES>> read,write,delete) policy: (unresolved org.jboss.naming.JndiPermission <<ALL BINDINGS>> lookup) policy:
So it seems like we can read the vfs entries into the policy file implementation. I need to still get the server to boot and report other problems. -
93. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 11, 2008 11:26 PM (in response to adrian.brock)I have been able to get AS5 started up with the url handler stubs. It worked exactly as DML claimed. Before we inject our version of URLStreamHandlerFactory in AbstractServerImpl, the url handler stubs help in the policy file implementation reading the vfs entries.
As the VFSClassloaderPolicy starts creating CodeSource URLs with the vfs urls, the url stream handler factory would have already been injected thereby flushing the pre-registered vfs handler stubs and the intended vfs handlers are created.
http://anonsvn.jboss.org/repos/jbossas/trunk/testsuite/src/resources/securitymgr/server.policy is the updated server security manager policy.
Web class loaders have a codesource url of "vfsfile" while others use "vfszip". We still have some protection domains with file: usage.
At this time, we need no change from CL and VFS projects.
The JDK implementation takes care of a defined vfs policy url such as:grant codeBase "vfszip:${jboss.server.home.dir}/lib/-" { permission java.security.AllPermission; };
and implies the following protection code url:codeBase "vfszip:${jboss.server.home.dir}/lib/some.jar"
Thanks to DML.
Hopefully I should enable the security manager tests tomorrow. Currently, I have 2 out of 67 tests failing (which is not sec mgr related). -
94. Re: VFS Permissions - JBMICROCONT-149
starksm64 Nov 12, 2008 12:16 AM (in response to adrian.brock)Who-Hoo!
-
95. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 13, 2008 12:23 PM (in response to adrian.brock)If I have a code source url that is based in memory,
10:25:57,774 ERROR [STDERR] access: domain that failed ProtectionDomain (vfsmemory://3j001-p6eal-fnhm0rta-1-fnhm1297-6/ <no signer certificates>) null
how will we assign permissions in the policy file if the path to the url is not the same across runs? Will the "3j001-p6eal-fnhm0rta-1-fnhm1297-6" be the same across multiple runs?
I cannot figure out from:
http://anonsvn.jboss.org/repos/jbossas/projects/vfs/trunk/src/main/java/org/jboss/virtual/MemoryFileFactory.java
UPDATE: that memory based vfs url is not constant across runs. -
96. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 13, 2008 11:59 PM (in response to adrian.brock)https://jira.jboss.org/jira/browse/JBAS-4154 is closed, now that the AS5 boots under a security manager. 302 tests got enabled now. I currently have 6-7 failing tests.
Pending Items:
a) JIRA issues open in EJBTHREE and Messaging for privileged blocks.
b) Still the issue of VFSPermissions implying other perms.
Issues:
a) AOP uses vfsmemory:// pattern. Not sure about assigning perms to a codesource URL in memory. Maybe vfs real url may help. -
97. Re: VFS Permissions - JBMICROCONT-149
alesj Nov 14, 2008 3:53 AM (in response to adrian.brock)"anil.saldhana@jboss.com" wrote:
Will the "3j001-p6eal-fnhm0rta-1-fnhm1297-6" be the same across multiple runs?
As you already discovered in update,
no, it will not be the same, as this is GUID generated path in InMemoryClassesDeployer. -
98. Re: VFS Permissions - JBMICROCONT-149
alesj Nov 14, 2008 3:57 AM (in response to adrian.brock)"anil.saldhana@jboss.com" wrote:
Issues:
a) AOP uses vfsmemory:// pattern. Not sure about assigning perms to a codesource URL in memory. Maybe vfs real url may help.
And there are others - assembled stuff --> vfs://.
Plus users can add their own protocols. ;-)
Dunno what to do about those,
as they don't have logical 'real' representation. -
99. Re: VFS Permissions - JBMICROCONT-149
dmlloyd Nov 14, 2008 12:12 PM (in response to adrian.brock)There ought to be a way for AOP (and anyone else using vfsmemory) to assign a symbolic (repeatable) name to the codesource. Obviously this would have to be established in a secure manner though (so that you couldn't just take someone else's name to get their permissions).
This way, users could reasonably assign permissions to their code, but also the code that their code generates. -
100. Re: VFS Permissions - JBMICROCONT-149
dmlloyd Nov 14, 2008 12:39 PM (in response to adrian.brock)(100th reply!!!!)
-
101. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 14, 2008 12:43 PM (in response to adrian.brock)"alesj" wrote:
"anil.saldhana@jboss.com" wrote:
Issues:
a) AOP uses vfsmemory:// pattern. Not sure about assigning perms to a codesource URL in memory. Maybe vfs real url may help.
And there are others - assembled stuff --> vfs://.
Plus users can add their own protocols. ;-)
Dunno what to do about those,
as they don't have logical 'real' representation.
We can deal with custom protocols. But we would need some static content in the URL that goes into the codesource url.
Something like:<protocol>://<static>/<dynamic> vfsmemory://jboss/microcontainer/uuid-string
Then the onus is on the system administrator to adequately assign permissions. I still see issues with rogue applications trying to mess in memory.
Maybe Scott/Adrian can think of something.... -
102. Re: VFS Permissions - JBMICROCONT-149
starksm64 Nov 14, 2008 12:44 PM (in response to adrian.brock)If we need to be able to assign permissions to vfsmemory urls, then it should map to the codebase from which the aspect was loaded in terms of having consistent permission assignments. It should just be inheriting the permissions of the aspect codebase. I don't see a usecase for assigning a separate permission to the generated code from the aspect.
-
103. Re: VFS Permissions - JBMICROCONT-149
dmlloyd Nov 14, 2008 12:48 PM (in response to adrian.brock)Correct me if I'm wrong though, but isn't that one of the usecases of aspects themselves? You can limit the permissions of codebase X and use aspects to wrap unprivileged code with a privileged operation like set up TCCL/transaction context/security context/etc.? In this case, the permissions of the aspect would be the aspect codebase plus some small fixed set of permissions. Though perhaps in this case it would be up to the aspect deployment to specify this?
Disclaimer: I'm no AOP expert :) -
104. Re: VFS Permissions - JBMICROCONT-149
anil.saldhana Nov 14, 2008 12:54 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
If we need to be able to assign permissions to vfsmemory urls, then it should map to the codebase from which the aspect was loaded in terms of having consistent permission assignments. It should just be inheriting the permissions of the aspect codebase. I don't see a usecase for assigning a separate permission to the generated code from the aspect.
For AS5GA, we are taking that approach by at least adding privileged blocks to users of aspects (such as ejb3, mc etc).
Examples:
https://jira.jboss.org/jira/browse/JBMICROCONT-385
Disclaimer: I am neither AOP nor VFS expert. I am also not Adrian Brock.