gcj-security and some issues

Tue Apr 27 10:23:00 GMT 2004

Am Die, den 27.04.2004 schrieb Michael Koch um 09:26:
> Am Dienstag, 27. April 2004 09:11 schrieb Jakob Praher:

> Your analysis seems quite correct BUT the biggest problem yet is that 
> StackTrace's implementation is just crap. The solution you provided is 
> nearly the same I did here some days ago until I found out that 
> StrackTrace is so dumb (it calls external apps to analyze the 
> stack ...). Bryce McKinley is working on a better solution. The base 
> has to be built first before we can build the roof.
>totally agree on that.
thanks for the info.
Obviously I haven't looked at StackTrace impl in detail.
My sketch was anyways too naive, since I think this would cost too much
to do it this way. 
It would be interesting if the vm would be "smart" enough to perhaps,
provide a set of protectiondomains with the current Methods/class in the
Stacktrace. 
Perhaps some kind of constant access time constraint would be great.
(Also some really fast short cut of access testing, if the classes come
from the bootstrap loader)
* I *think* there are much less ProtectionDomains in an
AccessControlContext compared to the amount of Methods on the call
stack. So simply iterating over all methods on the stack trace is too
expensive. 
* From experience I would assume that the CodeSource in the security
policy is often based on wildcards, and the CodeSource the vm assigns
the class is explicit. You don't have that much codebases in your policy
file anyway. So it would be an interesting issue, to don't have
excessive ProtectionDomains. Scaling with the amount of grants of a
policy file.
(If you've read Component Development for the Java Platform, or look at
the javadoc for SecureClassloader, you'll see that it defines a
defineClass with a CodeSource instead of a ProtectionDomain, this I
think is because of the chaching of ProtectionDomains).
The best would be if we could assert that there are no two
ProtectionDomain instances which are the same. This would reduce an
equals operation to a identity comparison. Or we should have a very
efficient hashcode method on that class).
Anayways I am looking forward to seeing the work of Bryce McKinley. 
And thanks for the info.
--Jakob