JBossDeveloper

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.

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 !

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

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;
};

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:

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;
};

codeBase "vfszip:${jboss.server.home.dir}/lib/some.jar"

Who-Hoo!

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

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.

"anil.saldhana@jboss.com" wrote:
Will the "3j001-p6eal-fnhm0rta-1-fnhm1297-6" be the same across multiple runs?

"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.

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.

(100th reply!!!!)

"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.

<protocol>://<static>/<dynamic>

vfsmemory://jboss/microcontainer/uuid-string

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.

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 :)

"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.