Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Shankar Unni <shankar@co...> - 2004-05-01 00:34:26
|
> I believe my changes are correct for any environment > BeanShell is used in. If you think differently, post a single > example where you believe BeanShell should be able to violate > Java's protected and private access controls. Scripted access is used for a lot of things. There's a reason Java makes the internals of classes visible via reflection: various stub- and glue-type packages need to reach into and access and modify private data members. White-box testing involves peeking into the internals of classes and verifying their state. It's not appropriate to enforce "strict java semantics" in this environment. Like I said, if the deployer of the beanshell package wants to enforce strict java semantics, that's up to them. Not to the final user of the scripting package, and also not to the implementors of BeanShell. |
|
From: Mark Swanson <mark@ScheduleWorld.com> - 2004-04-30 22:39:24
|
Hello,
I'm happy to announce BeanShell now works in an unsigned JWS env!
(There is still the Sytem property problem to solve, but no one has commented
on my proposed fix yet. Nudge...)
The supplied patches are all that is necessary. There is a major ramification
to this: BeanShell can no longer be used to violate protected and private
classes, members, or attributes. For many reasons I feel this is a very good
thing. Even people running with no SecurityManager should not be messing with
private constructors/methods/attributes, and there should never be a need to.
As a side note, this is quite interesting. C++ developers have always been
able to cast away 'const' correctness. Java developers are able to use
Reflection. In the unsigned JWS environment there is finally a perfect place
where you can 100% enforce your public contracts. You can't pull any
classloader tricks, nor any reflection tricks to bypass the contract. In a
way, you don't have to trust BeanShell because you don't have to - it can
only call public methods.
If I was using a scripting language to build or augment a web[site,app] or an
application I would want to use a scripting language that worked in an
environment I could trust. Now bsh can.
I'm looking forward to some good arguments to allow BeanShell to continue to
violate protected/private classes/members/attributes :-)
Cheers.
********** XThis.java patch:
(ctor MUST be public)
Index: XThis.java
===================================================================
RCS file: /cvsroot/beanshell/BeanShell/src/bsh/XThis.java,v
retrieving revision 1.23
diff -u -3 -p -r1.23 XThis.java
--- XThis.java 21 Apr 2004 04:17:37 -0000 1.23
+++ XThis.java 30 Apr 2004 22:06:01 -0000
@@ -67,7 +67,7 @@ class XThis extends This
InvocationHandler invocationHandler = new Handler();
- XThis( NameSpace namespace, Interpreter declaringInterp ) {
+ public XThis( NameSpace namespace, Interpreter declaringInterp ) {
super( namespace, declaringInterp );
}
********** Reflect.java patch:
Index: Reflect.java
===================================================================
RCS file: /cvsroot/beanshell/BeanShell/src/bsh/Reflect.java,v
retrieving revision 1.51
diff -u -3 -p -r1.51 Reflect.java
--- Reflect.java 21 Apr 2004 04:17:37 -0000 1.51
+++ Reflect.java 30 Apr 2004 22:09:51 -0000
@@ -366,7 +366,8 @@ class Reflect
while ( clas != null )
{
try {
- field = clas.getDeclaredField(fieldName);
+ field = clas.getField(fieldName);
+ //field = clas.getDeclaredField(fieldName);
ReflectManager.RMSetAccessible( field );
return field;
@@ -484,7 +485,8 @@ class Reflect
Class c = clas;
while( c != null )
{
- Method [] m = c.getDeclaredMethods();
+ Method [] m = c.getMethods();
+ //Method [] m = c.getDeclaredMethods();
for(int i=0; i<m.length; i++)
mv.add( m[i] );
c = c.getSuperclass();
@@ -572,7 +574,8 @@ class Reflect
{
try
{
- meth = c.getDeclaredMethod( name,
types );
+ meth = c.getMethod( name, types );
+ //meth = c.getDeclaredMethod( name,
types );
// Is the method public or are we in
accessibility mode?
if
( ( Modifier.isPublic( meth.getModifiers() )
@@ -640,7 +643,9 @@ class Reflect
use declared here to see package and private as well
(there are no inherited constructors to worry about)
*/
- Constructor[] constructors = clas.getDeclaredConstructors();
+ // MS: accessing private is a bug
+ Constructor[] constructors = clas.getConstructors();
+ //Constructor[] constructors = clas.getDeclaredConstructors();
if ( Interpreter.DEBUG )
Interpreter.debug("Looking for most specific
constructor: "+clas);
con = findMostSpecificConstructor(types, constructors);
********* New JWSTest.java
(The Swing deadlocks were because of my test code. I knew the original code
was wrong but (like all of Sun's examples prior to 2004) never saw it break
before. Neat.)
//
// $Id:$
//
import bsh.Interpreter;
import java.io.*;
import java.util.*;
import javax.swing.*;
/**
*
*/
public class JWSTest {
public static void main (String args[]) throws Exception {
JWSTest jwsTest = new JWSTest();
jwsTest.test();
}
void test() throws Exception {
InputStream is =
this.getClass().getClassLoader().getResourceAsStream("bsh/commands/printBanner.bsh");
if (is == null) {
System.out.println("rats");
System.exit(-1);
}
/*Interpreter i = new Interpreter(); // Construct an interpreter
i.set("foo", 5); // Set variables
i.set("date", new Date() );
Date date = (Date)i.get("date"); // retrieve a variable
System.out.println("date:" + date);
// Eval a statement and get the result
i.eval("bar = foo*10");
System.out.println( i.get("bar") );
// Source an external script file
//i.source("test.bsh");
*/
final JFrame frame = new JFrame("Bean Shell");
bsh.util.JConsole jConsole = new bsh.util.JConsole();
jConsole.setSize(600, 400);
bsh.Interpreter interpreter = new bsh.Interpreter(jConsole);
new Thread(interpreter).start();
frame.getContentPane().add("Center", jConsole);
frame.setLocation(600, 400);
//frame.pack();
SwingUtilities.invokeLater(new Runnable() {
public void run() {
frame.setVisible(true);
}
});
}
}
Cheers.
--
VoIP SIP:266368@...
Free calendar client and server - works with Exchange/Outlook/Yahoo!
TV-Listing and Weather Schedules
http://www.ScheduleWorld.com/
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp (JWS)
|
|
From: Shankar Unni <shankar@co...> - 2004-04-30 23:01:22
|
Mark Swanson wrote: > I'm happy to announce BeanShell now works in an unsigned JWS env! Yay. But hold your horses.. > In a way, you don't have to trust BeanShell because > you don't have to - it can only call public methods. That's wonderful, but your posted diffs enforce this unconditionally, rather than only in a "secure" environment. BeanShell is used for a lot more than "publicly safe scripting interfaces", so such a change is inappropriate. BeanShell already has an interface called "setVisible(true)" which is supposed to enforce such visibility rules, and any change should be done in conjunction with that - if setVisible(false) has been called, *then* call only getMethods() etc., instead of getDeclaredMethods(). Then, in your JWS environment, you can call "setVisible(false)" and get secure reflective access. Also, the XThis constructor change (package protected to public) is interesting: why did you do this? (I could use this change, too!). |
|
From: Mark Swanson <mark@ScheduleWorld.com> - 2004-04-30 23:41:20
|
On April 30, 2004 7:00 pm, Shankar Unni wrote:
> Mark Swanson wrote:
>
> > In a way, you don't have to trust BeanShell because
> > you don't have to - it can only call public methods.
>
> That's wonderful, but your posted diffs enforce this unconditionally,
> rather than only in a "secure" environment. BeanShell is used for a lot
> more than "publicly safe scripting interfaces", so such a change is
> inappropriate.
I believe my changes are correct for any environment BeanShell is used in. If
you think differently, post a single example where you believe BeanShell
should be able to violate Java's protected and private access controls.
> BeanShell already has an interface called "setVisible(true)" which is
> supposed to enforce such visibility rules, and any change should be done in
> conjunction with that - if setVisible(false) has been called, *then* call
> only getMethods() etc., instead of getDeclaredMethods(). Then, in your JWS
> environment, you can call "setVisible(false)" and get secure reflective
> access.
I am a BeanShell newb, but I do not believe BeanShell has a "visible" control
attribute. I've grep'd all of the code for "-iH visible {}" and none of the
code around anything with "visible" in it has anything to do with reflection.
Also, I searched the documentation and bshcommands manual and found nothing
on 'visible'. Where did you find documentation on this?
Hmm, further searching the commands revealed setAccessibility. I'm guessing
that's what you meant. If yes, I would like to put to the list that
setAccessibility() should be removed because:
1. I think it is wrong in any case to violate something so (sacred?) as
protected/private.
2. In my experience it is never a good idea to bypass the public interface.
Can anyone give a single good reason why they think this is a good idea?
>
> Also, the XThis constructor change (package protected to public) is
> interesting: why did you do this? (I could use this change, too!).
XThis must have a public ctor or it will be invisible to interpreted bsh code.
One of the required *bsh files for starting up the JConsole uses it so it had
to be changed.
Cheers.
--
VoIP SIP:266368@...
Free calendar client and server - works with Exchange/Outlook/Yahoo!
TV-Listing and Weather Schedules
http://www.ScheduleWorld.com/
http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp (JWS)
|
|
From: Shankar Unni <shankar@co...> - 2004-05-01 00:34:26
|
> I believe my changes are correct for any environment > BeanShell is used in. If you think differently, post a single > example where you believe BeanShell should be able to violate > Java's protected and private access controls. Scripted access is used for a lot of things. There's a reason Java makes the internals of classes visible via reflection: various stub- and glue-type packages need to reach into and access and modify private data members. White-box testing involves peeking into the internals of classes and verifying their state. It's not appropriate to enforce "strict java semantics" in this environment. Like I said, if the deployer of the beanshell package wants to enforce strict java semantics, that's up to them. Not to the final user of the scripting package, and also not to the implementors of BeanShell. |
|
From: Harish Krishnaswamy <hkrishnaswamy@co...> - 2004-05-01 01:04:20
|
Mark Swanson wrote: >Hmm, further searching the commands revealed setAccessibility. I'm guessing >that's what you meant. If yes, I would like to put to the list that >setAccessibility() should be removed because: >1. I think it is wrong in any case to violate something so (sacred?) as >protected/private. >2. In my experience it is never a good idea to bypass the public interface. >Can anyone give a single good reason why they think this is a good idea? > > > I am using the package protected classes from the Beanshell API to access its AST. So if this is to happen I would like to have access to the ASTs in another form. In any case I think a scripting language should be more forgiving and liberal than a strictly typed language and when such access is possible even in a strict language like Java, it makes no sense to me to make such restrictions in Beanshell. -Harish |
|
From: Mark Swanson <mark@ScheduleWorld.com> - 2004-05-01 01:25:05
|
On April 30, 2004 6:39 pm, Mark Swanson wrote: > > I'm looking forward to some good arguments to allow BeanShell to continue > to violate protected/private classes/members/attributes :-) OK, I think Shankar and Harish have given good reasons to allow protected/private access. Thanks fellas. So I think the patches need to be smarter. Here's my plan: 0. Keep default access to protected/private 1. setAccessible(true) performs a test to see if the env allows it. If not, warns the user. setAccessible(true) test should be called at bsh init(). 2. The few reflection points I changed will be wrapped with the accessible check. 3. Since no one has commented on my System properties solution I'm going to assume no one has a problem with it. I actually don't even know how many system properties there are and if they are for debugging only perhaps this is moot. 4. It's pretty important (critically actually) that certain public methods _never_ get called in the Interpreter. Does anyone have any suggestions on how I can prevent a few known methods from executing? Cheers. -- VoIP SIP:266368@... Free calendar client and server - works with Exchange/Outlook/Yahoo! TV-Listing and Weather Schedules http://www.ScheduleWorld.com/ http://www.ScheduleWorld.com/sw/ScheduleWorld.jnlp (JWS) |
|
From: Pat <pat@pa...> - 2004-05-01 17:59:57
|
Hi Mark, I'll take a look at the patches you sent and we'll see how we might best work them into both the accessible and safe modes... I'm sure it won't be a problem to have the reflection API make a few decisions differently based upon the mode. I recall looking at this after you first contacted us but there were a few details to sort out. Pat |