# Re: java.securty.AccessControlContext

Roland Schemers (Roland.Schemers@Eng)
Mon, 27 Oct 1997 00:00:28 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Clark Evans: "RE: java.securty.AccessControlContext"
- Previous message: Roland Schemers: "Re: java.securty.AccessControlContext"
- In reply to: Clark Evans: "RE: java.securty.AccessControlContext"

    From: Roland.Schemers@Eng (Roland Schemers)

    Message-Id: <199710270800.AAA11162@crypto.eng.sun.com>

    Subject: Re: java.securty.AccessControlContext

    To: clark.evans@gartner.com (Clark Evans)

    Date: Mon, 27 Oct 1997 00:00:28 -0800 (PST)

    In-Reply-To: <199710270642.AA09246@interlock.gartner.com> from "Clark Evans" at Oct 27, 97 01:43:57 am

>
> Two more question, if you have time.
>
> #1) If I create a AccessControlContext in thread A and
> pass this Context to thread B is there a way
> for thread A to specify some sort of expiration criteria?
> This context should not last "forever". Perhaps an
> expiration object is needed (an object can be called
> to see if the context is still valid)?

Did my answer to the last question clear this up? The context should
be associated with some sort of event or request, and the thread handling
the event/request can check that the thread that initiated the request/event
had permission to do so.

Typically it would look like:

somecode calls -> foo.bar.Request

foo.bar.Request gets the current context, and submits that request
to a thread, queue, etc. foo.bar.HandleRequest gets executed in
another thread at some point in the future, and can call checkPermission
on the context object to see if indeed the original caller had permission
to make the request. Note that foo.bar.HandleRequest and foo.bar.Request
must trust eachother and play by the same rules.

Another option to look at would be to use a GuardedObject. Thread B
could handle the request (perhaps after checking the context), and then
store the results in a GuardedObject. When thread A attempts to retreive
the results from the GuardedObject, an AccessController.checkPermission
call will be made at that time, using thread A's current context.

> #2) AccessController.beginPrivleged(), endPrivleged()
> seem to be handling the same kind of problem
> from a different angle. Are these things one and the
> same? (Where the System thread is loaning an
> AccessControlContext to the Application thread
> by using the begin/end privileged?)

Nope. begin/endPrivileged simple informs the AccessController that
if I (the current stack frame) have permission to do something, then
don't bother checking my caller.

For example, if system code has to read a file, or load a library,
even if it was called by untrusted code, it would do something like:

somemethod() {

FileInputStream fis = null;

try {
AccessController.beginPrivileged();
fis = new FileInputStream(someSystemPropertyFile);
} finally {
AccessController.endPrivileged();
}

}

Then if an applet (which didn't have permission to read the
property file) called somemethod, the begin/endPrivileged would
allow system code to read the property.

If you have your own permission object, you might do something
similar. For example, if you normally do something like:

X()
{
AccessController.checkPermission(myPerm);
...
}

And you also have a method Y, which you knows calls X, and you want
the call to always succeed, you would do something like:

Y()
{
try {
AccessController.beginPrivileged();
X();
} finally {
AccessController.endPrivileged();
}
}

Note that anyone can call beginPrivileged, it doesn't give the caller any
permissions that they don't already have.

roland

- Next message: Clark Evans: "RE: java.securty.AccessControlContext"
- Previous message: Roland Schemers: "Re: java.securty.AccessControlContext"
- In reply to: Clark Evans: "RE: java.securty.AccessControlContext"