# JDK 1.2 Security "Enhancements"

Joseph J. DiCelie (dicelie@meitca.com)
Wed, 19 Nov 1997 12:57:44 -0500 (EST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: George Chung: "IdentityScope in practice"
- Previous message: Jan Luehe: "Re: What happened to the Java Security Q&A archives??"
- Next in thread: Roland Schemers: "Re: JDK 1.2 Security "Enhancements""

    Date: Wed, 19 Nov 1997 12:57:44 -0500 (EST)

    Message-Id: <199711191757.MAA09505@dpw.meitca.com>

    From: "Joseph J. DiCelie" <dicelie@meitca.com>

    To: java-security@web2.javasoft.com

    Subject: JDK 1.2 Security "Enhancements"

In reviewing the JDK Early-Access Documentation, I came across the
following comment related to JDK 1.2 security.

>JDK 1.2 Java Security Architecture
>
> 7.3 More on Access Control
>
> The new access control mechanism is fully backward compatible.
> For example, all check methods in SecurityManager are still supported,
> although some of their implementations are changed to be call AccessController.
> Note that certain internal security checks may stay in the SecurityManager
> class, unless it can be parameterized.
>
> We have not at this time revised all JDK system code to call AccessController
> instead of calling SecurityManager (and checking for the existence of a
> classloader), because of the potential of existing third-party applications that
> subclass the SecurityManager and customize the check methods.

I hope the JDK system code will never change to call the AccessController
instead of calling the SecurityManager.

Those of use who have spent a great deal of time implementing custom
security policies, rely on the fact the JDK system code calls the
SecurityManager to check access permissions.

In addition it is unclear to me how I would create custom security
policies.

I understand I can create my own type of permissions, but checking would
still be based on Code Signers and Code Bases. If I want something
different, I guess I could create my own Policy class. This is the part
that is unclear. Regardless, this would still require me to undo all of
the custom SecurityManager work I have already done.

Having the default SecurityManager behavior be to call AccessController
I believe is perfectly reasonable. Not allowing me to create an
Alternate SecurityManager that is called by the JDK system code is, in my
opinion, unreasonable.

For the same reason I do not believe inClass, inClassLoader, classDepth,
classLoaderDepth and inClassLoader should be deprecated.
While using AccessController may be Suns preferred way of doing things,
it may not be mine.

Thank you,
Joe DiCelie
----------------------------------------------------------------------------------------------------------------------
Joseph J. DiCelie Mitsubishi Electric ITA
dicelie@metica.com 300 Third Avenue
(781) 466-8310 Waltham, MA 02154

"Unite for Java! - http://www.javalobby.org"

- Next message: George Chung: "IdentityScope in practice"
- Previous message: Jan Luehe: "Re: What happened to the Java Security Q&A archives??"
- Next in thread: Roland Schemers: "Re: JDK 1.2 Security "Enhancements""