Re: Custom Security Manager Questions

Ed Smiley (esmiley@meridian-data.com)
Mon, 06 Jan 97 09:42:39 PST

Date: Mon, 06 Jan 97 09:42:39 PST
From: "Ed Smiley" <esmiley@meridian-data.com>
Message-Id: <9700068525.AA852572861@smtpgate.meridian-data.com>
To: br@doppio.eng.sun.com (Benjamin Renaud)
Subject: Re: Custom Security Manager Questions


Thanks. I was confused as to whether the main() method (which as you point out
is a bootstrap mechanism when invoked by launching the class directly) would
exhibit the same behavior when invoked from somewhere else. Since it behaves as
an ordinary static method, you wouldn't get them threaded off; since I wanted to
avoid modifying the code of a1, a2, etc. (treat them as a black box) that
wouldn't do.

Clearly if I chose to implement it through Runtime.exec() I'd get a thread for
each runtime for free, and I would get the ability to implement different
SecurityManagers as well. I was starting to incline to that approach after I
contacted you on Friday. What I think I am going to do (note that I am
simplifying) have a stub exec program launch individual instances of the Exec_er
program through Runtime.exec(). Exec_er would then only exist to start (its
own) thread and set a SecurityManager and then call ax.main().
In case you are wondering why the heck I am trying to do something so bizarre:
my application (or the part I am working on) needs to have the ability to take
Java applications, unmodified and without access to source, and run them under
an externally determined Security Manager.

Again thanks for the patient help.

______________________________ Reply Separator _________________________________
Subject: Custom Security Manager Questions
Author: br@doppio.Eng.Sun.COM (Benjamin Renaud) at Internet
Date: 1/3/97 5:54 PM


Hi Ed,

This is indeed the right address for your questions.

[...]

| Say I have an application called Exec_er.class.
| Also I have applications called a1.class, a2.class, etc.
| Exec_er installs a custom Security Manager right off in its main method.
| It then launches a thread that loops through a periodically updated list
| of classes and proceeds to instantiate a1, a2, ... as a1inst, a2inst etc.
| then invoking a1inst.main(); a2inst.main()...
|
| The reason I am looking at this design is that I want to launch
| "fork off" complete child applications determined at runtime from a
| runtime engine (which I call Exec_er). Rather than doing a true launch
| through the OS (exec'ing "java a1"...), I want to get the applications
| running independently in tandem, but restricted by the Security Manager I
| put in place.
|
| My questions are as follows:
| 1. Will each class inherit the Security Manager in effect when the main()
| method was called, that is to say, in Exec_er? I'd think yes.

It depends on how you end up doing it. There is one SecurityManager
per VM. This means, that when you type

> java Exec_er

at the command line, you're starting one java VM. If from that VM you
"load and start" other classes such as your a* classes), they will
share the same VM, and consequently the same security manager.

Note that if you were to use Runtime.exec, you would be starting a
different Java VM, with a different SecurityManager.

| 2. Will each main() method (a1inst.main(); a2inst.main()...)get a
| separate thread of execution? I would think so as well.

main is a normal static method. It is used by the interpreter to as a
bootstrap mechanism, but when it is invoked normally at runtime, it is
simply just another static method.

To do what you want to do, you should have a1, a2, etc be runnable,
and start separate threads for each one from Exec_er. See the Java
Programming Language by Ken Arnold and James Gosling,
Addison-Wesley. Chapter 9 is on how to use threads.

I hope this answers your questions.

Cheers,
-- Benjamin
JavaSoft, Security Group

Received: from mdi.meridian-data.com by smtpgate.meridian-data.com (SMTPLINK V2.10.08)
; Fri, 03 Jan 97 17:53:58 PST
Return-Path: <br@doppio.Eng.Sun.COM>
Received: from venus.Sun.COM (venus.Sun.COM [192.9.25.5]) by mdi.meridian-data.com (8.6.11/8.6.9) with ESMTP id RAA05201 for <esmiley@meridian-data.com>; Fri, 3 Jan 1997 17:40:54 -0800
Received: from Eng.Sun.COM ([129.146.1.25]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA00103 for <esmiley@meridian-data.com>; Fri, 3 Jan 1997 17:54:37 -0800
Received: from doppio.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3)
id RAA01885; Fri, 3 Jan 1997 17:54:36 -0800
Received: from springbank.eng.sun.com by doppio.eng.sun.com (SMI-8.6/SMI-SVR4)
id RAA09500; Fri, 3 Jan 1997 17:54:16 -0800
Received: by springbank.eng.sun.com (SMI-8.6/SMI-SVR4)
id RAA21425; Fri, 3 Jan 1997 17:53:25 -0800
Date: Fri, 3 Jan 1997 17:53:25 -0800
From: br@doppio.Eng.Sun.COM (Benjamin Renaud)
Message-Id: <199701040153.RAA21425@springbank.eng.sun.com>
To: "Ed Smiley" <esmiley@meridian-data.com>
Cc: java-security@java.Eng.Sun.COM
Subject: Custom Security Manager Questions
In-Reply-To: <9700038523.AA852340527@smtpgate.meridian-data.com>
References: <9700038523.AA852340527@smtpgate.meridian-data.com>