# Re: java.security.Main and java.app.class.path

Roland Schemers (Roland.Schemers@Eng)
Sun, 16 Nov 1997 19:24:22 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: James McKeogh: "Javakey question"
- Previous message: Coimbatore J Srinivas: "JCE"
- In reply to: Coimbatore J Srinivas: "JCE"
- Next in thread: Jan Luehe: "Re: JCE"

    From: Roland.Schemers@Eng (Roland Schemers)

    Message-Id: <199711170324.TAA22784@crypto.eng.sun.com>

    Subject: Re: java.security.Main and java.app.class.path

    To: david@oxymoron.ora.com (David Flanagan)

    Date: Sun, 16 Nov 1997 19:24:22 -0800 (PST)

    In-Reply-To: <199711162231.OAA01000@oxymoron> from "David Flanagan" at Nov 16, 97 02:31:32 pm

> The addition of an application class path that is distinct from the
> system class path is a wonderful idea.
>
> However, I'm convinced that it will go unutilized if we have to deal
> with the java.security.Main. And worse, if we have to edit our system

Thanks for the comments. The existing java.security.Main and
java.app.class.path are stop-gaps that will hopefully be removed
in the FCS product. The current thinking is that the existing CLASSPATH
setting will be used for the same purpose that "java.app.class.path"
was going to be used for. The semantics of CLASSPATH will be changed
such that you can't use it to replace system classes. System
classes will reside in a new path (which I can't recall at this point)
and classes added to CLASSPATH/-classpath will always be searched after
the system class path.

The will also be a command-line option to enable/disable a security
manager and/or enforcement of the policy.

> I have some other comments on the "Java Security Architecture"
> document:
>
> * In the discussion of java.util.PropertyPermission, you don't say what
> the allowed actions are. I reading a property the only possibility.
> What about setting its value?

In the version you a reading, PropertyPermission had no actions, as all
you could do is grant permission to read them. However, we have since
added a new method (java.lang.System.setProperty) which allows someone
to set a single property. We have now added "read" and "write" actions to
PropertyPermission.

> * In the discussion of java.lang.RuntimePermission, you characterize
> "exit", "setFactory", "thread", and so on as the various targets for
> this Permission. I think it would be clearer to call these things
> actions instead of targets. Especially since most of them are verbs.
> Same for java.awt.AWTPermission, except that you may want to rename the
> actions so they are verbs...

There has been some discussion on this. Leaving them as targets gives
us a little remove in the future to add actions. For example, actions
could be "allow", "ask", disallow" (although we aren't planning at this
point to allow negative permissions). We might also change the names from
"exit" to something like "allowExit", or "exitVM". We'll probably
re-investigate changing them to actions though.

> * In the BNF grammar for the policy file (section 3.3.1), there is an
> error on the last line. The terminal "signed by" already appears in the
> SignerEntry non-terminal, so it should not appear on the last line of
> the OnePermission non-terminal.

Thanks, and thanks for the comments.

roland

- Next message: James McKeogh: "Javakey question"
- Previous message: Coimbatore J Srinivas: "JCE"
- In reply to: Coimbatore J Srinivas: "JCE"
- Next in thread: Jan Luehe: "Re: JCE"