# Re: JDK 1.2 Security "Enhancements"

Roland Schemers (Roland.Schemers@Eng)
Wed, 19 Nov 1997 12:29:23 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: George Chung: "JDK 1.2, please provide SSL interfaces and "force" :-) browser vendors to provide implementations"
- Previous message: ck2.eom.net@209.136.73.161: "SPECIAL INTERNET PRICES ON CHILDREN'S BOOKS!!"
- Maybe in reply to: Joseph J. DiCelie: "JDK 1.2 Security "Enhancements""

    Date: Wed, 19 Nov 1997 12:29:23 -0800 (PST)

    From: Roland Schemers <Roland.Schemers@Eng>

    Subject: Re: JDK 1.2 Security "Enhancements"

    To: java-security@web2.javasoft.com, dicelie@meitca.com

> 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 existing SecurityManager calls we are currently leaving them
in for backwards compatability and are changing the default bevahior
to call the AccessController. Thus you can still have an alternate
SecurityManager for these calls. You can also use super.check* in
your SecurityManager to include the AccessController check if you'd
like.

However, instead of adding new SecurityManager methods in each release
of the JDK (which doesn't scale) or having people incorrectly overload
existing methods, we are directly inserting AccessController checks into
the code.

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

Those checks have proven to be extremely error prone as they lead to
very brittle code. For example, a call that uses classLoaderDepth
will break if new system code is added that happens to call another method
which eventually results in a security check. What used to check for a depth
of "3" or "4" now breaks. We are also moving to a model where there will
be multiple class loaders installed (i.e, for extensions), thus just
checking to see if a class loader is on the stack is not sufficient.

The new security model cleans up a lot of these problems, with the
AccessController algorithm, privileged blocks, being able to create
new Permissions instead of adding new methods to the SecurityManager, etc.
It will be possible to create your own Polcy objects as well, as in the
latest version Policy is abstract and there is a setPolicy method. That
along with the ability to write your own class loaders and extend CodeSource
should still give people the functionality they need.

We would eventually like to see application developers be able to get
out of the job of writing security managers, as writing security managers
is a non-trivial exercise, and it makes the experience for the end user
troublesome, as each application has a different security manager, etc.

thanks, roland

- Next message: George Chung: "JDK 1.2, please provide SSL interfaces and "force" :-) browser vendors to provide implementations"
- Previous message: ck2.eom.net@209.136.73.161: "SPECIAL INTERNET PRICES ON CHILDREN'S BOOKS!!"
- Maybe in reply to: Joseph J. DiCelie: "JDK 1.2 Security "Enhancements""