[adrian.brock]

Giving tests all file read access and fixing the property access solves the problems.
I still don't know whether there are file permission problems inside the xml parsing?

However, there is some commonly used code:

package org.jboss.util;

 public static String replaceProperties(final String string)
 {
 return replaceProperties(string, System.getProperties());
 }

Which is used in lots of places (probably some of them incorrectly or duplicatively?)

I don't think it is correct to fix the privileged operation here since it would affectively
allow anybody to read a system property as a string.

However, if you know one of the other places (e.g. JBossXB) you could
find out the system property anyway just by deploying some xml (if I fix JBossXB).

[adrian.brock]

I've resolved the later issue (StringPropertyReplacer) by
using the default value when the caller context does not have access to the
system properties.

A debug message is logged (maybe this should be the more visible warning?).

[adrian.brock]

The previous behaviour was to throw an AccessException (even when there was
property replacement to be done).

[aloubyansky]

I have still created

need to use privileged actions
http://jira.jboss.com/jira/browse/JBXB-36

Since I use reflection API directly.

[starksm64]

I'm just going to add the permission checking when there is an SM installed
since I don't want to break anybody that is using the listeners.

We should be able to disable this class from even attempting to install itself as the System.Properties, especially as its just a side-effect of accessing this class. This is a poor contract for installing behavior as we have seen.

[adrian.brock]

Jira Task: http://jira.jboss.com/jira/browse/JBAS-2391

[starksm64]

The previous behaviour was to throw an AccessException (even when there was
property replacement to be done).

That was arguably the correct behavior though. This is just a system property lookup after all.

[adrian.brock]

As I mentioned on the other thread to Alex.
There are a number of bootstrap linkages in jboss-commons that need review.
e.g. installing property editors (although in this case,
we already agreed that we should be using our own contextual repository).
or protocol handlers, etc.

[adrian.brock]

The previous behaviour was to throw an AccessException (even when there was
property replacement to be done).

That was arguably the correct behavior though. This is just a system property lookup after all.

Yes, but it is not initiated by the application, it is initiated by the JBoss software,
in this case JBossXB (even when the property escaping isn't used).

What about if I change it to allow "null" in the properties to mean
System.getProperty() and then allow the access exception to leak back?
i.e. there is no need to do System.getProperties() upfront.

That way, the user would have initiated the system property request by specifying the
property escape in the xml.

[starksm64]

Ok, I agree we need to review the commons package and refactor as needed.

[starksm64]

Yes, but it is not initiated by the application, it is initiated by the JBoss software, in this case JBossXB (even when the property escaping isn't used).

So, JBossXB could have a priviledged action for this access, but as you say, this essentially introduces the ability to read system properties. Since this is still really a user initiated read, the permission check should propagate. The problem is that this is a promicious access to the system properties even when not needed.

What about if I change it to allow "null" in the properties to mean
System.getProperty() and then allow the access exception to leak back?
i.e. there is no need to do System.getProperties() upfront.

That way, the user would have initiated the system property request by specifying the property escape in the xml.

This makes the most sense and solves the uneccessary access to the system properties.

[adrian.brock]

Giving tests all file read access and fixing the property access solves the problems.
I still don't know whether there are file permission problems inside the xml parsing?

I tried hard-wiring the file permission to only give the test code access to its resources

public class TestsPolicyPlugin extends PolicyPlugin
{
 public PermissionCollection getPermissions(CodeSource codesource)
 {
 URL url = codesource.getLocation();
 File file = new File(url.toString());
 String name = file.getName();
 if (name.indexOf("tests") != -1)
 {
 Permissions result = new Permissions();
 result.add(new FilePermission("/home/adrian/jboss-head/workspace/kernel/src/resources/xml-test/-", "read"));
 return result;
 }
 return allPermissions();
 }
}

The good news is that all the tests pass, I do see the debug warning mentioned
above.

The bad news is that I have no idea how to do this generically? And in such a way
that it works inside eclipse and from junit running inside ant.

So I can't regression test this at the moment. :-(