# RE: java.securty.AccessControlContext

Clark Evans (clark.evans@gartner.com)
Mon, 27 Oct 1997 21:36:04 -0500

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Roland Schemers: "RE: java.securty.AccessControlContext"
- Previous message: Charlie Lai: "Re: setEchoCharacter and some more"

    Message-Id: <199710280234.AA24864@interlock.gartner.com>

    From: Clark Evans <clark.evans@gartner.com>

    To: "'Roland.Schemers@Eng.Sun.COM'" <Roland.Schemers@Eng>

    Subject: RE: java.securty.AccessControlContext

    Date: Mon, 27 Oct 1997 21:36:04 -0500

Roland,

Sorry to continually bug you about begin/end and
AccessControlContext, but I still do not understand why
they are needed. I *am* trying hard to understand....

> > The openFileForSearching is part of the explorer class, which
> > has the approprate permissions, it is on the top of the stack:
> >
> > ..., searcher.run(),explorer.openFileForSearching()
> >
> > Why is a begin privleged required?
>
> No, you would pass this object to the untrusted "search applet" code.
> At that point you do have untrusted code on the stack, thus the begin/end
> is needed. The untrusted search applet could call this method (which
> is in a different protection domain) to have it open the file.

Hmmm. Ok, startsearcher() would have to pass itself to
the (untrusted) searcher object before it started the
thread. Thus, (resorting to source code...)

startsearcher()
{

String strSearcher = Lookup("Searcher");
ClassLoader loader = new RestrictedClassLoader(...);
Searcher aSearcher = (Searcher) loader.loadClass(strSearcher, true).newInstance();
// Now a new searcher object is in a different protection domain...
// Current Security Stack: explorer.main(),explorer.startsearcher()
//
// Also assume that this "thread's security context" has the permission to do
// anything to the file system....
//

aSearcher.setExplorer(this);
// Setting the explorer...

aSearcher.start();
// Start explorer in another thread...

// Return to main "event loop"
}

Now the run method is invoked in the new searcher.

setExplorer(Explorer obExplorer)
{
this.obExplorer = obExplorer;
}

run()
{
// Referencing 4.3 "Inheritance of Access Context" we know that each
// thread gets its own "new stack".
//
// Furthermore, since this thread is "untrusted" it does not "inherit"
// the security context of the parent thread, thus this thread
// does not have file system privlieges.
//
// Stack: searcher.run()
//
// Read file so it can be searched....

FileInputStream aFile = obExplorer.openFileForSearching("MyFile");

// Do stuff with file.
}

Before we continue with the openFileForSearching call, is
there a determinstic way to know that the Searcher is untrusted?
Do the class loaders have to be different? Or do the package
names have to be different, does like: xxx.core.Explorer and xxx.addin.Searcher?

Anyway, the system now goes back to the explorer implementation:

public FileInputStream
openFileForSearching(String filename)
{
// Stack: searcher.run(), obExplorer.openFileForSearching()
//

if (fileIsOk(filename)) {
try {
AccessController.beginPrivileged();
return new FileInputStream(filename);
} finally {
AccessController.endPrivileged();
}
}
}

Thus the Explorer object (obExplorer) currently exists in a
trusted domain that allows full file access. The searcher
is in an untrusted domain that limits access.

Revised questions:

A) Why is the begin/end Privleged needed? I do not see
the security breach.

B) Why cannot the Explorer object simply "give" a permission
to the searcher that allows the files needed to be read for
a limited time? (By extending it's AccessControlContext..)

Thanks Tons and sorry to be trying...

Clark

- Next message: Roland Schemers: "RE: java.securty.AccessControlContext"
- Previous message: Charlie Lai: "Re: setEchoCharacter and some more"