# RE: java.securty.AccessControlContext

Roland Schemers (Roland.Schemers@Eng)
Mon, 27 Oct 1997 11:33:18 -0800 (PST)

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

    Date: Mon, 27 Oct 1997 11:33:18 -0800 (PST)

    From: Roland Schemers <Roland.Schemers@Eng>

    Subject: RE: java.securty.AccessControlContext

    To: clark.evans@gartner.com

>
> 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 the current object on the top of the stack has permissions, then
there is no need to do a begin/endPrivileged.

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

If servlets are loaded via a class loader that correctly extends from
SecureClassLoader in JDK1.2, then they will be subject to whatever constraints
the policy constrains them to, the same way an applet started from an
appletviewer is. There will most likely be a new version of JWS that is
correctly integrated with the new features in JDK1.2.

roland

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