[4280] in java-interest
java-interest-digest V1 #238
daemon@ATHENA.MIT.EDU (java.sun.com!owner-java-interest-d)
Fri Dec 15 13:34:34 1995
From: java.sun.com!owner-java-interest-digest@asoft.msk.su
Date: Sun, 29 Oct 1995 13:08:49 -0800
To: java-interest-digest@java.sun.com
Reply-To: java.sun.com!java-interest@asoft.msk.su
java-interest-digest Sunday, 29 October 1995 Volume 01 : Number 238
In this issue:
Re: warp pointer?
Re: java-interest-digest V1 #236
Re: Finalize()
Re: netscape2.0b1J (java errors)
Testing Applets...
Re: imagemap?
object-oriented feature not supported: why??
another compiler bug -- specialization of abstract classes
Re: java on NT, Can't find class...?
Re: another compiler bug -- specialization of abstract classes
Re: How to do enumeration
October 27th issue of J*** Notes
RE: xerror (netscape 2.0b1J (java)
where to start
Java Questions
Re: netscape2.0b1J (java errors)
java menu events
Web security (was Please UNLOCK the power of Java)
----------------------------------------------------------------------
From: sdw@lig.net (Stephen D. Williams)
Date: Fri, 27 Oct 1995 21:15:22 -0400 (EDT)
Subject: Re: warp pointer?
...
> In summary:
>
> As long as mouses are not able to change position on their own, the pointer
> should not change position "on it's own".
>
> In such context mouving the pointer around on it's own is bad UI programming.
> As bad as using gotos. Thanks java developper team excluded them.
>
>
> >Thanks for your comments.
> I hope that the Java developper team will examine and study this carfully
> before taking a decision.
>
> It is true that it is always possible to add the feature in Java and that I'm
> free not to use it. But it is equivalent to gotos. It is also possible to
> add gotos in java and leave the choice to use them or not to the users.
> The reason for rejecting gotos in Java was that it is well known bad
> programming. My argument for disallowing application control of mouse
> movement is the same, it is bad UI programming. So for the Java team, I
> would say, stick to the logic.
>
> I would be gratefull to hear any counter examples riquiring the aplication
> to change the mouse movement/location.
Support for multiple input devices (or virtual devices), possibly being
translated by an application instead of the underlying system.
Support for simulation/playback.
> Your welcome.
> Bien cordialement,
>
> Ch.Meessen
- --
Stephen D. Williams 25Feb1965 VW,OH (FBI ID) sdw@lig.net http://www.lig.net/sdw
Consultant, Vienna,VA Mar95- 703-918-1491W 43392 Wayside Cir.,Ashburn, VA 22011
OO/Unix/Comm/NN ICBM/GPS: 39 02 37N, 77 29 16W home, 38 54 04N, 77 15 56W
Pres.:Concinnous Consulting,Inc.;SDW Systems;Local Internet Gateway Co.;28May95
------------------------------
From: ROCKY FIKKI <rfikki@paradise.littleblue.com>
Date: Fri, 27 Oct 1995 20:31:14 -0600
Subject: Re: java-interest-digest V1 #236
I have downloaded the release for win95 from sun(java)
whenever I save a source to disk my OS changes the file name
lets say its called JackhammerDuke.java it gets stored on my machine
as jackha~1.jav and when I try to compile it it I get error
saying javac can't read the file how can I eliminate this or get
around it?
- --
For those who dare, the possibilities are endless !!!
Rocky Fikki, Fax 816 228-0030
webmaster at Email rfikki@paradise.littleblue.com
http://paradise.littleblue.com/index3.html
------------------------------
From: flar@bendenweyr.Eng.Sun.COM (Jim Graham)
Date: Fri, 27 Oct 1995 19:25:44 -0700
Subject: Re: Finalize()
> The final few sentences is this footnote are somewhat alarming.
> How can finalize() be used for ANYTHING if it isn't reliably called?
Since the finalize() method is called from the garbage collector and
since the actions and timing of the garbage collector or implementation
dependent, you shouldn't rely on any consistency from it to invoke
your finalize methods.
Keep in mind that if the user has enough memory and if his current
running heap usage is fairly stable it may be a very long time until
the next GC cycle and so your finalize() method may not be called for
a *long* time. In the meantime if you need some system resource that
an unfinalized object is wasting, you may be out of luck if you were
depending on the garbage collector to finalize your class and restore
the system resources.
This is why when we call your paint and update methods with a Graphics
object we explicitly call the dispose() method on the object after you
are done painting even though dispose() is also called from the
finalization method. If we relied on the garbage collector to dispose
the GC's then we might have an indeterminate number of system GC
objects being wasted attached to old unreachable (but not yet
collected/finalized) Graphics objects...
...jim
------------------------------
From: ser@jersey.uoregon.edu
Date: Fri, 27 Oct 1995 22:05:36 -0700
Subject: Re: netscape2.0b1J (java errors)
> Cannot allocate colormap entry for default background
What are you running on?
Java, like some other applications, are not very nice when they can't take
control of the color map. If you are running on a Sparc with 8 bit
graphics and you have Netscape running at the same time, java applications
(including HotJava) will sometimes not work.
- --- SER
------------------------------
From: ser@jersey.uoregon.edu
Date: Fri, 27 Oct 1995 22:16:45 -0700
Subject: Testing Applets...
> Hi, I was wondering what the best way to test applets is. Reloading
> from the browser doesn't work since it just re-executes the program,
Start using the Beta release of Java. There is no other way to test
applets except by exiting and restarting HotJava. You could download
and install "Arthur's Applet Viewer"
(http://java.sun.com/applets/alpha/notapplets/appletviewer/index.html)
and use that; with some creative aliasing, it is almost easier to use
than restarting HotJava every time, and it is definitely quicker.
- --- SER
------------------------------
From: ser@jersey.uoregon.edu
Date: Fri, 27 Oct 1995 22:33:57 -0700
Subject: Re: imagemap?
> Can I have an imagemap-type link from
> a hot spot in an applet to some URL?
Yep. Go grab the ImageMap from:
http://java.sun.com/applets/alpha/applets/imagemap/index.html
It's not only a superior imagemap, but it's powerfully extensible,
as well. Another interesting example that allows you to specify areas
with masks (and pops up information in windows) is at:
http://www-i5.informatik.rwth-aachen.de/mbp/mapzine/test.html
If you are going to program your own, look at these examples for
inspiration. However, the easiest way to do it if you must do it
yourself is to intercept mouseDown() in your applet, check the x,y
coordinates, and then cause a load of the page your want. It's a lot
easier just to steal someone else's imagemap, though.
- --- SER
------------------------------
From: andruid@SPARKY.CS.NYU.EDU (Andruid Kerne)
Date: Sat, 28 Oct 95 02:26:36 EDT
Subject: object-oriented feature not supported: why??
its very nice that there is a class Class, and that for any
objectX of class ObjectX, you can say objectX.getClass();
Sometimes you'd like to be able to use that information to make a copy
of the objectX. Assuming there is a constructor,
ObjectX(ObjectX clone) { <whatever> }
Then if Java is an object-oriented language, you'd like to be able to say
ObjectX newObjectX = new objectX.getClass()(objectX);
However, the compiler says
'new(...)' not supported.
Are there any plans to support this kind of construction??
This is the sort of litmus feature which would bring the language up
from the realm of C++ into something much cleaner.
- --
Cheers,
Andruid Kerne
NYU Media Research Laboratory
--and also--
Creative Media Cauldron
http://c4dm.nyu.edu/andruid/
The distinctions between artists and engineers -- between content
developers and programmers -- are entirely artificial.
------------------------------
From: andruid@SPARKY.CS.NYU.EDU (Andruid Kerne)
Date: Sat, 28 Oct 95 04:27:45 EDT
Subject: another compiler bug -- specialization of abstract classes
It seems that the compiler rejects this because the argument is
declared as the abstract class. This looks wrong.
public abstract class Geometry
{
// various other code
public abstract Geometry minus(Geometry vTrans);
}
public class VectorFloat
extends Geometry
{
// various other code
public VectorFloat minus(VectorFloat vTrans)
{
// various other code
}
}
------------------------------
From: Christopher Wang <cwang@cs.columbia.edu>
Date: Sat, 28 Oct 1995 09:00:24 -0400
Subject: Re: java on NT, Can't find class...?
Hi,
I am very interested in Java and Hotjava and have just loaded Alpha3
for Win95 and NT (I have NT 3.51). Hotjava runs well and I can run a
local applet I compiled (Helloworld).
However, for some reason I can not run an application with plain
java. It ALWAYS returns the error "Can't find class helloworldapp".
No matter what I try to do with CLASSPATH or -classpath, or where I
put the complied class file, etc??? If I use the -verbose switch,
java indicates that it is loading all the needed classes, EVEN the one
in question, but when it goes to run it, NO dice.
I think I had this problem. Is your class names helloworldapp or
Helloworldapp? Even though NT is case insensitive, it seems that java
is not. Weird. Anyways let me know if this fixes the problem.
------------------------------
From: Arthur.Vanhoff@Eng.Sun.COM (Arthur van Hoff)
Date: Sat, 28 Oct 1995 10:28:39 -0700
Subject: Re: another compiler bug -- specialization of abstract classes
Hi Andruid,
> It seems that the compiler rejects this because the argument is
> declared as the abstract class. This looks wrong.
We don't support co-variant subtyping of return types in overriding
methods. Methods only override each other if the signatures are identical!
Have fun,
Arthur van Hoff
------------------------------
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
Date: Sat, 28 Oct 1995 14:06:39 -0700
Subject: Re: How to do enumeration
> Is there a enumeration class in java. Can somebody provide me
> with an example or alternative to do enumeration in java.
There are no classes per se, but java.util.Enumeration is an interface
implemented by many classes, including the collection classes in
java.util. Here's how one might enumerate a HashTable:
HashTable ht;
Enumeration e = ht.elements();
while (e.hasMoreElements()) {
Object o = e.nextElement();
...
}
Tom Ball
Java Products Group
------------------------------
From: mentor@io.org (David Forster)
Date: Sun, 29 Oct 1995 01:31:40 -0500
Subject: October 27th issue of J*** Notes
Hello all,
Once again, there's a new issue of J*** Notes available via
http://www.io.org/~mentor/J___Notes.html (don't forget to reload the page).
For those of you who do not know of this handy service, here's the standard
blurb:
Are you tired of wading through hundreds of messages on the Java-related
mailing lists to get to the real nuggets of information? Don't you wish
there was some place where you could just read the high points?
Well, search no longer!
Announcing J*** Notes!
J*** Notes is a weekly summary of the traffic appearing in the Java mailing
lists and news groups. We hope that the summaries are unbiased and a clear
reflection of what the various authors intended, but we are human,
so some errorrs or misconceptions may creep in.
Each issue contains entries in the following categories:
1.Announcements: brief notices of happenings, course offerings, etc.
2.Features: J*** Notes exclusives and summaries of important discussions
3.Discussions: summaries of multi-message exchanges
4.Bugs and Warnings: listings of known or suspected bugs or odd behaviour
5.Comments: short statements of fact or opinion
6.Queries: short questions, sometimes with answers
7.Class Exchange: Got a class to give away? Need a class developed?
8.FAQ candidates: questions of the FAQ sort, with answers
Please check out our latest issue today!
Cheers,
David Forster <br><a href="http://www.io.org/~mentor">
Mentor Software Solutions </a><br>
+1 905 832 4837 <br>
------------------------------
From: exceed@wwcd.com (exceed group)
Date: Sun, 29 Oct 1995 12:28:37 -0500
Subject: RE: xerror (netscape 2.0b1J (java)
- ----- Begin Included Message -----
From thollin@psci.net Fri Oct 27 14:05 EST 1995
Date: Fri, 27 Oct 95 13:09:01 PDT
From: "Thomas J. Hollinden" <thollin@psci.net>
Subject: RE: xerror (netscape 2.0b1J (java)
To: exceed group <exceed@wwcd.com>
MIME-Version: 1.0
In Xconfig Video, do you have "Preserve System Colors" checked? If you
do, you might try unchecking it.
- -------------------------------------
Name: Thomas J. Hollinden
E-mail: Thomas J. Hollinden <thollin@psci.net>
Date: 10/27/95
Time: 13:09:01
This message was sent by Chameleon
- -------------------------------------
Hi
Tried it, but with no luck.
Any other ideas?
Gary
------------------------------
From: ari@best.com (ari fainchtein)
Date: Sun, 29 Oct 1995 16:57:50 GMT
Subject: where to start
hi,
i am new in this field although i know c and other 4gl languages. I would
like to know of any books or articles that one can download about learning
hotjava that take one from the beginning.
takes in advance
ari
------------------------------
From: Venkat_Krishnamoorthy@fp.cibc.com
Date: Sun, 29 Oct 95 12:42:00 -0500
Subject: Java Questions
Hi there,
I have run in to some specific problems, while writing a standalone
java application.
platform: prebeta1a , solaris.
a). A part of my app gives user ability to submit jobs, so i spawn
a thread and do a runtime.exec("job"), Following is the code
fragment.
class BatchThread extends Thread{
public synchronized void run(){
Process proc=Runtime.getRuntime.exec("job);
proc.waitFor();
}
}
Problem:
-------
The first time i invoke this thread, things run fine, the
second time the thread waits for ever. If i do a ps, i see my child
as a zombie, Is this a bug or am i doing anything wrong.
b). Are there any code fragments to load gif images in a
"standalone app", Also any examples on using thread groups.
If you have any answers to any of the above please email
me directly at
"krishnam@fp.cibc.com"
Thanks,
-Venkat.
------------------------------
From: ser@jersey.uoregon.edu
Date: Sun, 29 Oct 1995 11:05:40 -0800
Subject: Re: netscape2.0b1J (java errors)
>>> Cannot allocate colormap entry for default background
>> What are you running on?
> Running on a pentium using Humingbirds exceed to the sun box which is
Ah. Are you running in 16-bit graphics mode? Java will crash if it is
run on any display that isn't 8 or 24 bit. Since there exists no Sun
hardware that is 16-bit graphics you get some odd effects when you try
to run Sun software on such a display.
If you are running in 8-bit mode, I imagine then that the problem is
because HotJava can't get enough colors; as I said, make sure you aren't
running netscape at the same time.
- --- SER
------------------------------
From: jsanders@excelsior-73.Eng.Sun.COM (Jim Sanders)
Date: Sun, 29 Oct 1995 13:01:13 -0800
Subject: java menu events
In a java application, how do you capture menu events?
Below is an application with a menu bar and a couple
of menus. There are also a couple of buttons
in the app. The "action()" routine captures the events
from buttons in the app, but not the menus.
Anybody have sample application code that deals
with events from menubar menus?
-Jim
// create menubar with two menus
import java.awt.*;
import java.applet.Applet;
public class menuBarTest extends Applet
{
public menuBarTest()
{
setLayout(new BorderLayout());
Panel p = new Panel();
p.setLayout(new FlowLayout());
add("South", p);
p.add(new Button("quit"));
p.add(new Button("Doit"));
}
public boolean action(Event evt, Object arg)
{
System.out.println("Event detected: " + arg);
if ("quit".equals(arg))
{
System.exit(0);
}
if ("Doit".equals(arg))
{
}
return true;
}
public static void main(String args[])
{
Frame f = new Frame("menuBarTest");
menuBarTest menuBarTest_test = new menuBarTest();
menuBarTest_test.init();
menuBarTest_test.start();
MenuBar mb = new MenuBar();
Menu h = new Menu("Help");
h.add("General Help");
h.add("Even More Help");
h.add("Extra Special Help");
mb.add(h);
mb.setHelpMenu(h);
Menu h2 = new Menu("File");
h2.add("New");
h2.add("Open");
h2.add("Close");
h2.add("Save");
h2.add("Exit");
mb.add(h2);
f.setMenuBar(mb);
f.add("Center", menuBarTest_test);
f.resize(300, 300);
f.show();
}
}
------------------------------
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Date: Sun, 29 Oct 1995 21:08:34 GMT
Subject: Web security (was Please UNLOCK the power of Java)
[cc:ed to java-interest for those not yet reading comp.lang.java]
I wrote:
>This suggests that resources should be given out on a need-to-know basis.
>Then, the user can quantify the risks involved, and any damage is limited to
>the specific files or resources the app was trusted with.
Here is a scheme that implements this style of security (it's ended up a bit
longer than I anticipated, but never mind). Comments and criticism are
welcomed.
~~~~~~~~~~
There are two distinct kinds of access: by name, and by capability.
Names include filenames, directory names, device names, class names,
protocol names, etc. Any app can make up a name, e.g. "/etc/passwd", and
request access to it (but obviously this does not always succeed).
Importing a class counts as accessing it by name.
Capabilities are handles that provide a given level of access to a resource.
Unlike names, capabilities are unforgeable; a client that possesses one must
have obtained it directly or indirectly from a trusted source. There are two
kinds of capability: references, which are only valid in one address space and
for a single execution of an app, and persistent capabilities, which don't
have these restrictions.
Names and capabilities can be converted as follows:
<pre>
.----> Reference
/ ^
Name |
\ v
`----> Persistent
capability
</pre>
Converting from a name to a capability (of either kind) is strictly controlled.
Random applets from the net can only access harmless things by name (for
example, the GUI classes). Some apps are trusted to directly represent the
user (e.g. a GUI or a command-line shell), and can access any resource that
the user can. Signed apps would be given some intermediate level of access.
Converting between a persistent capability and a reference is usually allowed
(it may not be allowed if the capability was created with restrictions on its
use - see later). References point to objects and can be used directly.
This means it is possible for an app to use resources that it cannot access
by name, if it has been given a capability for them. For example, if I type
this on a command-line:
myapp 'foobar.html'
myapp will receive a capability for foobar.html (as well as its name as a
string). The quotes '' indicate to the shell that a capability should be
passed.
In a graphical environment, resource names would be entered in trusted
controls or dialogues. The control gets a resource name from the user, and
returns both a capability and the name to the app. If the app attempts to
create a spoof control, it will not gain any information that it could not
have gained using the real one.
(NB. it is important that trusted controls should always be redrawn correctly,
and that the app should not be able to draw over them).
The default permissions for a capability, e.g. read, write, execute etc. for
files, are determined by the security context (see later) for the app that
receives it. The defaults can be overridden by the user on a case-by-case
basis, by selecting options in a trusted control or by adding extra flags on
the command line.
An app can request to upgrade a capability to a higher access level (which may
involve prompting the user for confirmation). It can also downgrade it to a
lower access level - this is useful if it wants to pass the capability to
another app that it does not trust completely.
Rationale
~~~~~~~~~
Capability systems work on the following heuristic:
Telling someone about a private resource is almost always associated with
giving them access to it.
This applies to programs as well as people; for a program to access a resource,
at some point the resource's name must have been entered. So it is an attract-
ive idea to link authorization directly with the act of specifying a name.
The problem with this is that names are forgeable. For example, the name
"/etc/passwd" is well known - I don't have to have told it to an app before
it can request access to that file. But if it was possible to guarantee that
all names were distinct in some sense, so that I have to tell the app about my
_specific_ /etc/passwd, this could potentially provide a good degree of
security.
This is precisely what the capability-passing scheme above attempts to
simulate. Whenever I enter a resource name in a secure way, the relevant app
will get a corresponding capability. It doesn't matter that the app may not
have the rights needed to resolve the name itself.
Concrete example: a recent post in comp.lang.java mentioned accessing a
serial port. Suppose this port has the resource name 'driver:com1'.
For a shell: the user types something like "myapp port='driver:com1'"
For a GUI: myapp displays a trusted control showing a set of device icons,
and the user clicks one of them.
In either case, only access to 'driver:com1', and nothing else is granted.
Note that a capability can encapsulate any object; in this case the object
might enforce the use of a particular protocol, or handle device conflicts,
or whatever. At some point code must be calling the native OS, and that code
must be trusted completely. However the levels above that can potentially
be written as user classes.
This scheme does not always protect the user from him/herself, in that a
user can type in a name (perhaps at the prompting of the app), without
necessarily understanding what it means. It would be possible to display
warning dialogues for the most serious cases, though.
Applications and applets
~~~~~~~~~~~~~~~~~~~~~~~~
In the present API the distinction between these is quite sharp. I would
prefer to see a continuum of app*s, ranging from ImageLoop-type things
to full-blown editors, equation solvers, mail programs, etc.
Running all of these in a unified framework would greatly increase
the opportunity for co-operation between them (I'll expand on this in
another article).
In the framework I'm suggesting, applets are just apps with severely
restricted rights to access resources by name. It should also be possible to
write a shell or browser as an app, without having to treat it as a special
case.
Security contexts
~~~~~~~~~~~~~~~~~
Access levels are determined by security contexts. A security context holds
any available security information about a class or running app, for
example where it came from, whether it was signed and who by, whether it
has been installed persistently in a particular directory, etc.
It also stores a security policy (which can be assigned independently for each
app or class). The security policy is responsible for interpreting the other
information in the context to decide which requests are granted. (The interface
java.lang.SecurityManager in the beta API does something similar to this,
although I think it needs to be made much more flexible).
In more detail: security contexts are associated with both classes, and
thread groups (see the class java.lang.ThreadGroup). When a shell or browser
runs a program, it starts by running a method of a particular class. The
security context for that class is used as the security context for the thread
group.
A class can make each request for a resource using either its class security
context, or the current thread group context. This is similar to the
distinction between setuid programs and normal programs in Unix (except
that it applies to individual classes instead of users, and each request
instead of all a program's requests). For example, when an app uses a
trusted GUI control, the control uses its class context to look up the name
entered by the user. If it used the thread group context, the request would
probably be denied.
Implementing persistent capabilities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A persistent capability must have the following properties:
- - it specifies a unique resource and access level
- - it cannot be forged
- - it is 'just data' (a reference is not just data, because it has very
specific rules on how it can be manipulated, and is only unforgeable if
these rules are followed).
To meet these requirements, the capability must be chosen from a large
space of values, only a small (and unpredictable) fraction of which are
valid. Although in theory an attacker could guess the right one by luck,
this can be made arbitrarily unlikely.
One way of achieving this is to pair the resource name and access level
with a cryptographically secure random number. The run-time system
stores a table of these pairs, and checks on each access whether the correct
random number has been given. A capability can be revoked by removing
its entry from the table.
Another way is to digitally sign or encrypt the name and access level to
ensure it cannot be forged. (The choice between these is a tradeoff between
the checking time vs space for the table of pairs.)
A persistent capability can be associated with an 'acceptance condition' that
determines when it is valid (i.e. when it can be converted to a reference), and
what to do if it isn't.
For example, it is possible to create capabilities that are only valid for a
given length of time. Using the table implementation, this condition would
be stored in the table, e.g. as the predicate (current_time () < expiry_time).
These conditions don't have to be hardwired into the security system (e.g. as
user, group, world permissions are hardwired into Unix); they can be any
function of the capability, the security context (which includes the class and
app making the request), and the resource being accessed.
Secure persistent data
~~~~~~~~~~~~~~~~~~~~~~
A special case of an acceptance condition, could be to deny access to a
resource unless the requesting app is signed using a particular private key.
This is useful for controlling access to persistent data.
For an app to store persistent data, it must allocate a directory. Directories
are resources, so the app first prompts for the directory name using a trusted
dialogue. The resulting capability allows it to create the directory, and at
this point it can associate a public key with it. The app should be signed
using the corresponding private key.
Directories created in this way have quotas, and files created in them cannot
be symbolic or hard links to locations outside the directory.
Apps that are not signed with the appropriate private key cannot access the
directory by name (they may be able to access it via a trusted dialogue, i.e.
by asking the user nicely). This keeps apps partitioned from one another,
unless the user specifically requests it or the apps are signed using the same
private key.
Any app can request a list of the directories it is allowed to access by name,
but should not necessarily be able to see other directories.
Transferrability
~~~~~~~~~~~~~~~~
Since persistent capabilities are just strings of bits, they can be
duplicated, stored on disk, sent across the network, encrypted, signed, etc.
It also means they are potentially transferrable; if I email you a capability,
then all other things being equal, it will give you the same access to that
resource that I have.
For example, suppose I download an app from X, and give it a persistent
capability. Assuming the app is allowed network access, it can send this
capability back to X. X can email the result to Y, and when I download an
app from Y, it may be able to access the same resource.
This is sometimes a potential security hole, and sometimes very useful. The
question is whether trust is transitive, i.e. whether
A trusts X with R, and X trusts Y with R => A trusts Y with R
In general this depends what the resource, R, is. If it is read-only data,
then it is inevitable that Y will be able to access it, because the data
itself is copyable.
If the resource represents a service, or allows write access to something,
this is much less clear, and should probably be decided by A.
Fortunately the framework I've described can handle either option. It is
possible to 'stamp' a capability with information about who it was originally
given to (or any other information, in fact), so that removing the stamp
invalidates the capability - one way is to encrypt or sign the capability
after adding the information.
When a request using that capability is received from some other app, the stamp
can be used to decide whether to accept it.
Note that if capabilities are being transferred over the network, ideally the
channel should be encrypted, and both ends of the connection should be
authenticated.
Summary
~~~~~~~
Access to a resource is either by name or capability.
Names are forgeable; capabilities are not.
As well as files, names include directories, classes, protocols, etc.
Capabilities are either references, or are persistent. A capability can refer
to any object that encapsulates a resource.
A shell or GUI starts with access to all or most names (it is a trusted agent
of the user).
Apps from the net start with access to few harmless names.
An app can gain further access rights by being granted capabilities.
A shell grants a capability when the user enters a name on the command line.
A GUI grants a capability when the user enters a name in a trusted control
or dialogue.
There is a security context for each class, and each thread group.
When a thread group is started by calling a particular class, its security
context is used as the thread group security context.
The security context for the current thread group is used to determine default
access levels.
These access levels can be overridden when requesting each capability.
The access level for a capability can be upgraded or downgraded.
Persistent capabilities are implemented as (name, random key), or anything
else that encodes the name and is unforgeable.
Access conditions can be attached to a persistent capability, limiting when
it can be used.
Capabilities can be transferred between programs, either on the same system
or (if persistent) over the network.
It is possible to detect when a persistent capability has been transferred, by
stamping it with the user it was originally given to.
Although this scheme may sound complicated at first, most of the possibilities
arise from orthogonal combinations of a few basic ideas: capabilities, trusted
controls, and security contexts. For a different way of implementing
capabilities, see 'CACL: Efficient Fine-Grained Protection for Objects' in
OOPSLA (Object-oriented systems, languages and applications) 1992.
I will be implementing a prototype of this system; any help or suggestions
would be appreciated. One of the problems is that source for Sun's implement-
ation of the beta API has not yet been released (could anyone from Sun give
a date for this?).
David Hopwood
david.hopwood@lmh.ox.ac.uk
------------------------------
End of java-interest-digest V1 #238
***********************************
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
