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

David Flanagan (david@ora.com)
Sun, 16 Nov 1997 14:31:32 -0800

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Coimbatore J Srinivas: "JCE"
- Previous message: Pekka Nikander: "Funny export restrictions for downloading JCE 1.2 API Specification"

    Date: Sun, 16 Nov 1997 14:31:32 -0800

    Message-Id: <199711162231.OAA01000@oxymoron>

    From: David Flanagan <david@ora.com>

    To: java-security@web2.javasoft.com

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

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
properties file to specify the application class path, or type that path
all the time. It is just too much typing; too inconvenient to bother to
use. It would only be workable when used in batch files, but I don't
see (untrusted) application distributors going to the trouble of writing
batch files that utilize java.security.Main. That would just be asking
for trouble--their users would run into policy configuration
difficulties, and think that the application was difficult to install.
So it really is going to be up to the user to enforce this kind of
security, and I just don't see myself being willing to do all that extra
typing just to try out an application.

I can see that you don't want to make this the default behavior for
compatibility reasons. Your suggestion of using a -s option to Java is
an okay one. Instead, though, why not simply check to see if
the system property java.app.class.path or the environment variable
APPCLASSPATH is defined? If either is defined, then use its value as
the application class path and follow the new behavior. If neither is
defined, then use the old behavior.

Seems simple to me, but I'm not a security guru...

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

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

David Flanagan
david@oreilly.com
O'Reilly & Associates

- Next message: Coimbatore J Srinivas: "JCE"
- Previous message: Pekka Nikander: "Funny export restrictions for downloading JCE 1.2 API Specification"