# RE: java.securty.AccessControlContext

Clark Evans (clark.evans@gartner.com)
Mon, 27 Oct 1997 11:15:37 -0500

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

    Message-Id: <199710271613.AA23969@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 11:15:37 -0500

Roland,

Thank you for clearing up AccessControlContext.
Very Nice! :)

I am still a bit mystified why begin/end is needed.

Roland you wrote:
> 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.

>From my understanding of the security document the
current stack frame begins with the main() method of
a class. Thus a class does not "start" with system
level security... (obvious..)

Now, assume the current object (on the top) of the stack
frame wants to do something, and if it innately has the
permission to do so (system code), is there a reason why it
normally should not? Why does it need to enable its
permissions? Is this just for system methods?

If it is just for system methods, then I think that the same
problem re-occurs in application code, for instance:

Take the JavaWebServer and its servlets,the same pattern
happens again here, only the "beginning of the security
stack" is the run() method of the thread for a servlet.
>From my understanding of 4.3 (Inhertence), these servlets
will be inheriting the security level of the web server? *ouch*

In away, this is the *same* problem only at the application
domain level. Am I making sence? Or did I just miss the boat?

Perhaps the opposite of begin/end privleged is what is required,
this will let anyone clear the permissions by explicitly
granting them where appropriate...

somemethod()
{
try
{
beginRestricted( <optional list of restricted permissions > );

// start threads,
// call other objects,
// Only the "Restricted" permissions are inherited by the
// created thread and calls to "untrusted" classes are limited
// to the permissions listed in the restricted section.

}
finally
{
endRestricted();
}
}

Also, the more I think about this, it could be done with
a callback / inner class in a much "cleaner" way...

class MyClass
{
class DoRestricted implements ExecuteRestrictedCallback
{
public void DoRestricted()
{
// start threads,
// call other objects,
// Only the "Restricted" permissions are inherited by the
// created thread and calls to "untrusted" classes are limited
// to the permissions listed in the restricted section.
}
}

somemethod()
{
executeRestricted(
new DoRestricted,
<optional list of restricted permissions > );
}
}

I like this better since it does not give opportunity to forget about the "end"....
Also, it provides for pretty nice seperation of code.

This mechinism solves part of the begin/end thingy, it makes the inherited
permissions on the call stack / creating new threads explicit... there is still
no way to check to see if a permission was on the "permission stack" before
the current method. Idea:

Extend CheckPermission(perm) to handle one more parameter:
stackObject. This extra parameter (if supplied) stops the
scanning of the security stack when it reaches the stackObject.
In this way, AccessController.CheckPermission(perm,this) will check
to see that the current thread of execution had the given permissoin
"before" methods from this object were called..... this
will help to solve the second part to the begin/end restricted.

I hope this makes sence, if I have missed the boat, would you
please show me where I made the wrong turn?

Thanks again for your time!

Clark

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