Ingo == Ingo Prötel [EMAIL PROTECTED] writes:
Ingo would like to propose a modification to Toms fix. It looks to me as if
Ingo all fields of a deserialized object are accessible as well as the
Ingo private readObject-Method. Or does the VM reset the Accessible flag?
No, nothing resets the flag.
Hi,
would like to propose a modification to Toms fix. It looks to me as if
all fields of a deserialized object are accessible as well as the
private readObject-Method. Or does the VM reset the Accessible flag?
I think we need to reset the accessible flag after we are done with the
field or
On Tuesday 05 August 2003 01:43, Bryce McKinlay wrote:
The performance implications of all this are also rather concerning -
walking up the stack is going to be fairly slow. But I presume that for
normal applications where security is not required (ie
System.getSecurityManager()), such checks
Hi,
On Tue, 2003-08-05 at 20:50, Tom Tromey wrote:
I assume you are doing this because your Class implementation caches
the Field and Method objects. I don't think that is valid. If we
call setAccessible on a Method, then even if we reset it we are
opening up a window where other
Bryce == Bryce McKinlay [EMAIL PROTECTED] writes:
Bryce But I presume that for normal applications where security is
Bryce not required (ie System.getSecurityManager()), such checks are
Bryce avoided?
Yes, the security manager itself walks the stack in this case, so if
there is no security
On Saturday, Aug 2, 2003, at 01:46 Pacific/Auckland, David P Grove wrote:
Hi Tom,
We've had security manager checks in the reflection code in Jikes RVM for a while. Our current workaround for serialization is that classes loaded by the system classloader are always allowed access.
On Monday 04 August 2003 01:53, Bryce McKinlay wrote:
On Saturday, Aug 2, 2003, at 01:46 Pacific/Auckland, David P Grove
wrote:
Hi Tom,
We've had security manager checks in the reflection code in
Jikes RVM for a while. Our current workaround for serialization is
that classes
On Monday, Aug 4, 2003, at 19:57 Pacific/Auckland, Chris Gray wrote:
Sure. But to call AccessibleObject.setAccessible() you need
ReflectPermission, which the user code that initiated serialisation
does not
necessarily have. So the java.io serialisation stuff needs to have
this
permission, and
On Monday 04 August 2003 11:02, Bryce McKinlay wrote:
On Monday, Aug 4, 2003, at 19:57 Pacific/Auckland, Chris Gray wrote:
Sure. But to call AccessibleObject.setAccessible() you need
ReflectPermission, which the user code that initiated serialisation
does not
necessarily have. So the
On Monday 04 August 2003 11:57, Jeroen Frijters wrote:
Chris Gray wrote:
Granting AllPermission to everything loaded by the system
class loader is IMHO acceptable, *iff* by system class
loader you mean the class loader which
loads java.* classes from a trusted location.
This is the
On Monday, Aug 4, 2003, at 21:33 Pacific/Auckland, Chris Gray wrote:
No. The security context of a given method invocation is the set of
classes
on the stack at the time of the invocation, and the resulting set of
privileges is the intersection of the privileges of all those classes.
So if
Hi Tom,
We've
had security manager checks in the reflection code in Jikes RVM for a while.
Our current workaround for serialization is that classes loaded by
the system classloader are always allowed access. This is probably
too big of a hole, but it does work in practice. The key routine
David == David P Grove [EMAIL PROTECTED] writes:
David If you come up with a finer-grained fix for libgcj, let me know
David -- I'm not that happy with what we are currently doing in Jikes
David RVM.
I checked in a couple patches last night that fix this problem.
Basically we now call
I recently added some security checking code to libgcj. In particular
we now do access checking for reflection: Method calls and Field reads
and writes.
This breaks serialization quite dramatically. Now uses of
serialization cause crashes, as we get into infinite recursion
catching and writing
14 matches
Mail list logo
