# RE: java.securty.AccessControlContext

Clark Evans (clark.evans@gartner.com)
Mon, 27 Oct 1997 13:30:31 -0500

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

    Message-Id: <199710271829.AA01732@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 13:30:31 -0500

Roland,

First, thank you for responding.

Second, this new security scheme is wonderful. I like
shifting responsibility for checking access from
the execution environment to the callee/resource/object.
Also,The Permissions object is great!
Very Very Very Nice. *much enthusiasm*

However, sorry to bug you more but I am still having trouble
understanding how some of these peices fit together.

The more I think about AccessControlContext the more I
cannot see a way it will be useful. Perhaps an example
would help. So that I am not nagging, here is an example
that I thought of (and why it does not work):

Suppose you have a "explorer" application that you have
one or more "applets" that are used to edit data items.
Both the explorer and applets are written by different
vendors. On a "folder" object, a "search" applet is launched.
The "explorer" application would like to hand off permission
to "read" all files in the folder that have the extensions
"txt", "doc", "text", etc.

How can I do this?

First, the explorer would create one or more FilePermission
objects, perhaps group them together in a Permissions
object. That much is obvious.

Next the explorer would launch the "search" applet, and
would like to give the search applet this permission.
Assume for a moment that this new "sub-thread" does not
inherit the explorers permissions... (which could be
devistating) or alternatively assume that the "explorer"
thread is a sub-thread of the window manager object and the
window manger object is going to create the "search" applet....

In any case, a message must be sent to the search applet from the
explorer applet to "search folder XXX" and the permissions to do so
need to be passed on.

Lets say that the search applet is going to make a bunch of java.io.*
calls to obtain the list of applicable files, open them, search, etc.

You wrote:
> The model/pattern is you have to re-write X.x, so that instead of
> calling AccessController.checkPermission, it calls checkPermission
> on the AccessControlContext.

Thus all of the java API calls will have an extra parameter that
will use a AccessControlContext instead of the current context?

I find that this completely undermines the purpose behind asking
the domain controller for the threads permissions... passing around
permission contexts does not sound like fun.

> Note that the code that creates the
> context in thread A should be "trusted". i.e., it should be from
> the same code base as the code being run in thread B.

How would this work for "untrusted code" ?

> Also note that in this model, thread B already has access to all the
> resources. It is simply checking the context to make sure the
> thread that initiated the request has permisions.

What if it does not have access? Why should we force the
user to edit the policies to add "read" to the search applet.
If this is the case, why even pass around a security
context anyway? I would see this to help "limit" the amound
of configuration by the user and do more of it dynamically.

Hmm. Perhaps there is an alternate solution....

When the explorer object sends a message to the search applet
it passes a PermisionsProxy object as well. The search applet
would then add the PermissionsProxy object to its current thread
context, by AccessController.addPermissionsProxy(proxyFromExplorer).

Now when the java.io.* asks for read permission to the file in
the folder, the PermissionProxy is queried for the permission if
the search applet does not already have it. Simple, no passing
around Contexts....

> 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?

To answer my question in this case, when the ProtectionProxy is
queried, the non-final method IsValid() first. In this way
applications can ovverride any criteria to determine when the
granted protections should expire...

Hmm.

Sorry to be a pain, just trying to figure out this security stuff.

BTW, nice job.

- Next message: Roland Schemers: "RE: java.securty.AccessControlContext"
- Previous message: Clark Evans: "RE: java.securty.AccessControlContext"