gcj-security and some issues
Wed Apr 28 23:36:00 GMT 2004
Tom> Eventually we'll be able to load multiple .so's via different class
Tom> loaders. So the mapping would have to be by the particular mapping,
Tom> not by, say, the .so's inode.
Jakob> hmm interesting. So you mean by that, that one could override the
Jakob> natClassLoader by some other shared object loader, or how shall I
Jakob> understand that? How does that affect the CodeSource, I mean the
Jakob> location doesn't change regardless which class loader is used.
Yeah, good point about CodeSource. It could affect the protection
The basic idea here is that the class->object mapping can be done
behind the scenes by the VM -- this is the gcj-jit idea that Andrew
has been hacking on. It doesn't involve explicit user code knowledge
of .so loading at all, it is handled automatically.
Jakob> setting the ProtectionDomain here is called from withtin the
Jakob> _Jv_RunMain. Does this mean this gets only done for a executable/shared
Jakob> object, that calls the RunMain function.
This patch only affects classes that are linked into the executable.
Classes loaded dynamically already have their protection domain and
code source set, either by the interpreter code that creates classes,
or by the code in natSharedLibLoader.cc.
Jakob> What is the job of the initiated_classes array. Does it contain all
Jakob> classes that are loaded and usable?
Look in natClassLoader.cc, there is a comment explaining all this
Anyway, if you're looking for something to hack on in this area, let
me suggest fixing AccessController, then writing Mauve tests for
various SecurityManager things. I think we'll find a lot of places
where we need doPrivileged() to be added; one or two showed up on the
classpath list recently. There's plenty of other tasks in this area.
As for dealing with protection domains and such, unless it is needed
immediately, let's leave it alone for a bit. This seems like
something to solve on the new abi branch.
More information about the Java