JBossDeveloper

/** JBCL-64: CodeSource should use read vfs url **/
 private boolean useRealURL = false;

 this.useRealURL = Boolean.valueOf(SecurityActions.getProperty("vfs.codesource.useRealURL", "true"));

private boolean useRealURL = true;
 this.useRealURL = Boolean.valueOf(SecurityActions.getProperty("vfs.codesource.useRealURL", "true"));

Ales, I did get brocked last year on the non-oo method pattern (previous iteration of the security deployer). Gosh, I should have learned from that mistake. ;)

"adrian@jboss.org" wrote:

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

"adrian@jboss.org" wrote:

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

Scott, I think we will need a custom policy post AS5GA to correctly get all the use cases, VFS has. At the moment, the criticality is that we have something like 100-200 tests currently disabled in the test suite because the AS cannot run under a security manager.

I did try out the jar url format (which of course turned out to be stupid) that could do nested wars in ears etc.

Right, so what was the solution Adrian said was working with vfs urls?

"scott.stark@jboss.org" wrote:
Right, so what was the solution Adrian said was working with vfs urls?

Actually make that VFSUtils.getRealURL(VirtualFile)

And I still like my suggestion of putting stub URL handlers on the boot classpath and then replacing them with a URLStreamHandlerFactory once things get spun up. :-) Then you get a security manager from the start, and additionally you can use the real URLs in codeSource.

"david.lloyd@jboss.com" wrote:
And I still like my suggestion of putting stub URL handlers on the boot classpath and then replacing them with a URLStreamHandlerFactory once things get spun up. :-) Then you get a security manager from the start, and additionally you can use the real URLs in codeSource.

"david.lloyd@jboss.com" wrote:
And I still like my suggestion of putting stub URL handlers on the boot classpath and then replacing them with a URLStreamHandlerFactory once things get spun up. :-) Then you get a security manager from the start, and additionally you can use the real URLs in codeSource.

protectiondomain that failed (vfszip://my.ear/something.war)
{ //I have been assigned permissions from the orphan "grant" entry}

Yeah, I got that. But my point was that by having stub URL handlers at VM startup, we *can* specify VFS URLs in security.policy, and the whole dirty mess can be avoided. Still checking to see if the behavior is consistent across various JVMs though. One hopes that this behavior is verified by the TCK, but there's only one way to find out...

OK, just tested - it works reliably in Sun, Apple, and IBM JDKs. I don't have JRockit handy to test with.

Here's my little test:

import java.net.URL;
import java.net.URLConnection;
import java.net.URLStreamHandlerFactory;
import java.net.URLStreamHandler;
import java.io.IOException;

public final class Main {

 public static void main(String[] args) throws IOException {
 final URL urlOne = new URL("http", "www.google.com", "/");
 final URLConnection conn = urlOne.openConnection();
 final Class<? extends URLConnection> origClass = conn.getClass();
 URL.setURLStreamHandlerFactory(new URLStreamHandlerFactory() {
 public URLStreamHandler createURLStreamHandler(final String protocol) {
 if (protocol.equals("http")) {
 return new URLStreamHandler() {
 @Override
 protected URLConnection openConnection(final URL u) throws IOException {
 return new URLConnection(u) {
 @Override
 public void connect() throws IOException {
 }
 };
 }
 };
 } else {
 return null;
 }
 }
 });
 final URL urlTwo = new URL("http", "www.google.com", "/");
 final URLConnection conn2 = urlTwo.openConnection();
 final Class<? extends URLConnection> newClass = conn2.getClass();
 System.out.println("First: " + origClass.getName() + ", second: " + newClass.getName());
 }
}

IRC with DML.

(02:18:46 PM) asaldhan: ping
(02:18:54 PM) dmlloyd: hey
(02:19:03 PM) dmlloyd: writing the test now :)
(02:19:11 PM) asaldhan: :) thx for that
(02:19:25 PM) asaldhan: how to inject the stub handlers into the bootstrap. can we do it via endorsed?
(02:19:35 PM) dmlloyd: easy, just add them to main.jar
(02:19:48 PM) dmlloyd: don't need endorsed at all
(02:19:54 PM) dmlloyd: we'll need to set a system property too
(02:20:18 PM) dmlloyd: but that's better than rewriting VFS at the last minute :) if it works anyway
(02:20:20 PM) asaldhan: u mean the pkgs sys property. right?
(02:20:58 PM) dmlloyd: yeah java.protocol.handler.pkgs
(02:21:04 PM) asaldhan: currently I think one of the vfs beans does the system.setprop(pkgs)
(02:21:09 PM) asaldhan: not done in the command line
(02:21:33 PM) dmlloyd: yeah, I think that's not the right approach - we should be using a URLStreamHandlerFactory instead
(02:21:44 PM) dmlloyd: once the container is bootstrapped I mean
(02:21:51 PM) asaldhan: right.
(02:22:18 PM) dmlloyd: I guess as a temp hack we could just plug in a URLStreamHandlerFactory that always returns null which will just effectively clear the cache
(02:22:26 PM) dmlloyd: then reset the sys property...
(02:22:39 PM) dmlloyd: I'd be a lot less sure of that working though
(02:24:28 PM) asaldhan: give it a shot with various jdk implementations.
(02:26:33 PM) dmlloyd: ok, well it definitely works on sun jdk (of course)
(02:26:39 PM) dmlloyd: next: apple...
(02:26:54 PM) asaldhan: jrockit is quite close to sun
(02:27:03 PM) asaldhan: so check with ibm if possible
(02:27:26 PM) dmlloyd: yeah I just downloaded IBM this morning
(02:31:35 PM) dmlloyd: works on apple...
(02:31:37 PM) dmlloyd: next IBM
(02:31:44 PM) asaldhan: good.
(02:38:16 PM) dmlloyd: works in IBM
(02:38:22 PM) dmlloyd: I don't have jrockit handy
(02:38:23 PM) asaldhan: sweet
(02:39:14 PM) dmlloyd: it's just a simple class, let me put it in a pastebin
(02:39:28 PM) asaldhan: do put it on the dev forum man
(02:39:31 PM) asaldhan: forget paste bin
(02:39:41 PM) asaldhan: just put it in the thread.
(02:40:54 PM) asaldhan: I peeked at the source of URL class and can see what u preach
(02:41:01 PM) asaldhan: handlers.clear()
(02:41:11 PM) dmlloyd: done
(02:41:43 PM) dmlloyd: yeah, I think it's all implied in the javadoc for URL.setStreamHandlerFactory()
(02:43:26 PM) asaldhan: yeah. Let me give this a shot.
(02:51:08 PM) asaldhan: dml
(02:51:17 PM) asaldhan: let me understand this:
(02:51:40 PM) asaldhan: we call this setSHF method at most ONCE
(02:51:43 PM) dmlloyd: right
(02:51:47 PM) asaldhan: so we install this factory.
(02:51:53 PM) asaldhan: which clears the handlers.
(02:52:14 PM) dmlloyd: yes
(02:52:22 PM) asaldhan: after that. we install the handlers?
(02:52:37 PM) dmlloyd: once it's installed, we could do it one of two or three ways
(02:53:29 PM) dmlloyd: (1) the handler could just be a dummy that always returns null - this will cause the default mechanism to be used. But if we do it this way, we'd have to change the value of the java.protocol.handler.pkgs property first (and I"m not 100% sure it won't just reuse the old cached ones in some cases - seems iffy to me)
(02:54:14 PM) dmlloyd: (2) we could install a handler that emulates the existing URL resolution behavior by looking up the classes by package name, taking into account the *real* VFS url handlers
(02:55:16 PM) dmlloyd: (3) we could design a URL handler loader POJO component which specifies an API for in-container URL handlers (most flexible but requires a new API for URLStreamHandlers - not a big deal but more work than (2))
(02:55:33 PM) dmlloyd: the safest & easiest would be (2) imo
(02:56:19 PM) dmlloyd: the URLSHF should be installed at the time when the MC would ordinarily set the "java.protocol.handler.pkgs" sys property
(02:56:35 PM) asaldhan: yeah, we can make this the first bean
(02:57:28 PM) asaldhan: if we have installed a SM, then the setSHF call go through the sm check, which means we have read the policy file (and the vfs entries thrown out)
(02:57:40 PM) dmlloyd: yes and no
(02:57:46 PM) dmlloyd: the vfs entries won't be thrown out
(02:57:52 PM) dmlloyd: that's the beauty of the whole idea :)
(02:58:05 PM) asaldhan: will give it a shot.
(02:58:27 PM) asaldhan: explain why the entries will not be thrown out
(02:58:34 PM) dmlloyd: why would they be?
(02:58:59 PM) asaldhan: because we have not installed the handlers
(02:59:06 PM) dmlloyd: the handlers don't need to be there
(02:59:15 PM) dmlloyd: the policy never uses them when loading the file
(02:59:18 PM) dmlloyd: it just checks that it's there
(02:59:33 PM) asaldhan: can I paste this chat into the forums?
(02:59:40 PM) dmlloyd: yeah, I was just going to do that :)
(02:59:43 PM) asaldhan: for archival purposes.
(02:59:51 PM) dmlloyd: go ahead


(03:09:07 PM) asaldhan: I think the classloading.xml has the VFSClassloader doing the Policy.getPolicy().getPermissions(Codesource). That is where we have the issue with vfs urls
(03:09:24 PM) dmlloyd: yes
(03:09:47 PM) asaldhan: at this stage, we should have had our protocol handlers registered.
(03:09:50 PM) dmlloyd: but again, it shouldn't actually be trying to open any real connections
(03:10:02 PM) asaldhan: policyFile implementation does that
(03:10:14 PM) asaldhan: it tries to canonicalize the url
(03:10:20 PM) asaldhan: wait
(03:10:21 PM) asaldhan: it does
(03:10:32 PM) asaldhan: url.openConnection().getPermissions()
(03:11:26 PM) dmlloyd: so our stubs should be returning a reasonable value
(03:11:38 PM) dmlloyd: maybe AllPermission is OK for the early-boot stage?
(03:11:44 PM) asaldhan: but
(03:12:07 PM) dmlloyd: or, a special early-boot RuntimePermission perhaps
(03:12:22 PM) asaldhan: http://anonsvn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloading-vfs/src/main/java/org/jboss/classloading/spi/vfs/policy/VFSClassLoaderPolicy.java
(03:12:42 PM) asaldhan: protected ProtectionDomain getProtectionDomain(String className, String path)
(03:12:46 PM) asaldhan: last line of that method
(03:14:40 PM) asaldhan: at this stage, our vfs entries need to be read
(03:14:53 PM) dmlloyd: it should be doable though
(03:15:13 PM) dmlloyd: the main issue is to get past main.jar
(03:15:44 PM) dmlloyd: like I said, the URLSHF should be installed at the time when the MC would ordinarily set the "java.protocol.handler.pkgs" sys property
(03:16:03 PM) dmlloyd: which would be fairly early in the bootstrap I guess
(03:16:35 PM) dmlloyd: or else, no later than just after the VFS URL handlers are available
(03:16:40 PM) dmlloyd: which I guess you already said :)
(03:17:14 PM) asaldhan: yeah we can install the SHF before the sys property for handlers
(03:17:53 PM) asaldhan: but at the time the policy entries are read, the vfs handlers should be there.
(03:19:00 PM) asaldhan: will give it a try
(03:19:15 PM) asaldhan: AND I sure hope u r right. :)
(03:20:28 PM) dmlloyd: if it doesn't work, we could switch to a variant of (3) where we create a sort of "LazyURLConnection" that uses the implementation when it becomes available