Class SecuritySupport and Class.forName( "java.security.AccessController ") 2003-01-14 - By neilg@(protected)
Hi Annette,
While your modification should work for your application, it won't work in
general because querying system properties is (potentially) an operation
requiring privilege. The whold point of the SecuritySupport classes is to
determine if the concept of operations requiring privilege exists in the
environment, and to implement appropriate behaviour if it does. You
wouldn't want a test of whether privilege is required itself to require
privilege. :)
You can freely modify the ObjectFactory code (as long as you abide by the
Apache license). To modify the JAXP code, you'll probably want to contact
Sun directly--especially if you plan to distribute the modified code; they
might require you to show that your modified code can still pass the
relevant TCK.
Bottom line: the sooner folks move off of the Java 1.1 platform, the
better for everyone. :)
Cheers,
Neil
Neil Graham
XML Parser Development
IBM Toronto Lab
Phone: 905-413-3519, T/L 969-3519
E-mail: neilg@(protected)
|---------+---------------------------->
| | "Doyle, Annette" |
| | <Annette.Doyle@(protected)|
| | sinfo.com> |
| | |
| | 01/14/2003 10:53 |
| | AM |
| | Please respond to|
| | xerces-j-user |
| | |
|---------+---------------------------->
>----------------------------------------------------------------------------
-----------------------------------------------------------------|
|
|
| To: <xerces-j-dev-subscribe@(protected)>
|
| cc: <xerces-j-user@(protected)>
|
| Subject: Class SecuritySupport and Class.forName("java.security
.AccessController") |
|
|
|
|
>----------------------------------------------------------------------------
-----------------------------------------------------------------|
We are using Microsoft's jview for our front end GUI and Sun's JRE 1.3 for
our backend (server). We have an auditing factory class that is used both
in our front end and backend. It is compiled under Sun's 1.3 compiler. This
auditing class uses the new xercesImpl parser to create a dom and read
configuration information. Now, the GUI ran fine on my machine and my
co-workers. However, when we deployed for integration testing, it failed.
The test integration machine has military secure software (COE) also on it.
What is happening, is that the integration test machine running jview is
loading the class java.security.AccessController from the class path set
by the military software. So, when the following classes
javax.xml.parsers.SecuritySupport and
org.apache.xerces.util.SecuritySupport execute the following code, they try
to run the SecuritySupport12 class because it finds the class
java.security.AccessController.
static {
SecuritySupport ss = null;
try {
Class c = Class.forName("java.security.AccessController");
// if that worked, we're on 1.2.
/*
// don't reference the class explicitly so it doesn't
// get dragged in accidentally.
c = Class.forName("javax.mail.SecuritySupport12");
Constructor cons = c.getConstructor(new Class[] { });
ss = (SecuritySupport)cons.newInstance(new Object[] { });
*/
/*
* Unfortunately, we can't load the class using reflection
* because the class is package private. And the class has
* to be package private so the APIs aren't exposed to other
* code that could use them to circumvent security. Thus,
* we accept the risk that the direct reference might fail
* on some JDK 1.1 JVMs, even though we would never execute
* this code in such a case. Sigh...
*/
ss = new SecuritySupport12();
} catch (Exception ex) {
// ignore it
} finally {
if (ss == null)
ss = new SecuritySupport();
securitySupport = ss;
}
}
I would like to change this code to get the java.version system property
and check for 1.1 (or 1.0) in java.version string. If found, then the
SecuritySupport class would be the instantiated, otherwise the
SecuritySupport12 class would be instantiated. Is there a reason why this
wouldn't work? Why is the above way used? Also, how do I get written
permission to change this for our implementation?
Thank you,
Annette Doyle
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-j-user-unsubscribe@(protected)
For additional commands, e-mail: xerces-j-user-help@(protected)
|
|
