[cap-talk] Polaris: the paper

Jed Donnelley jed at nersc.gov
Thu Dec 9 22:05:13 EST 2004


At 05:22 PM 12/9/2004, Karp, Alan H wrote:
>Jed Donnelley wrote:
> >
> > No, that text is there.  What I don't see is anything I recognize
> > as a "pet name" in one of the windows to distinguish it from
> > the other.  The windows have different top labels:
> >
> > << >> HP Labs - Microsoft In...
> > and
> > <<InternetExplorer>> HP Labs
> >
> > but I don't see how to map the above into anything that I would
> > understand as a "pet name".  Perhaps you can at least tell
> > me which one of the windows has the pet running in it, the
> > left (mostly blue) or the right (more purple/red)?
> >
>I've updated the paragraph to read
>
>"It is important that the user be aware of the security environment, but
>the cues should not be obtrusive [13].  As shown in Figure 4, Polaris
>modifies the title bar of the window running the application.  If a pet
>is running in the window, the pet name appears, <<InternetExplorer>> in
>the right panel.  If the application was not launched under Polaris, the
>pet name is left blank, <<>> in the left panel.  We also take advantage
>of a feature of Windows XP that let's us change the color of the title
>bar of windows running pets."

That addresses that issue and makes the distinction clear.  Thanks.

One question, though.  You say that "If the application was not launched
under Polaris, the pet name is left blank".  Does that mean for
applications launched *by* Polaris but not run as "pets" *under*
Polaris?  If not (namely the application is run directly on
Windows), how do you control what goes in the <<>> or even
put anything there?

Minor question with regard to color - do you restrict the colors
that can appear so as to make distinctions that applications
are not allowed to override?  More for my interest I think as
perhaps that's too find a point for the paper.

> > In Polaris the restricted user account has the authority to change
> > the original file, but only by virtue of the willingness of
> > the synchronizer
> > (with permissions to read the copy and write the original) to copy
> > updates to the copy back to the original.  The restricted user account
> > never gets permission to modify the original file directly.
>
>I've adopted pretty much this wording.
>
> > What distinguishes a "capability" is not how it's implemented
> > (in my opinion), but the fact that it's a bound entity that
> > can communicate a name for and rights to an object
> > in a single unit.
>
>Polaris doesn't have anything like this.  When the user clicks to open a
>file, we use the designation to add the authority, but that's the only
>time the desigination and the rights appear close to each other.

Right at the point the "capability" is communicated.  Seems
a natural to me.

> > For example, consider the DCCS (or pick another example more
> > than one layer to its rights communication - I use the DCCS
> > because it is old, simple, and probably most understand it,
> > though I admit I'm particularly familiar with it).  One could say
> > that a process has "permission" to access an object if it
> > has a capability to that object.  However, in the case of a
> > process with a remote capability, the right to the object is
> > abstracted one level.  That is, the right is only available by
> > virtue of the remote server processes and the protocol
> > (including the access control list mechanism) that they
> > support.  Does that mean that the remote process only has
> > "authority" to access the object and not "permission"
> > to access the object?  I argue no.
>
>I argue yes.  It is the behavior of the remote server process that gives
>the remote object the authority.  Breaking the connection removes the
>ability to use the object.

That's certainly true, but just use your magnification glass a bit and
you can find all sorts of other intermediaries which, if their contribution
was broken, would disable even the base capability mechanism.
On the other hand, from the point of view of a process in the DCCS
with some capabilities, they all contribute direct "permissions"
to it.  It has no need to know (and indeed might not be able to
know) that there is any sort of indirection involved with some.
It would certainly not occur to such a process to consider some
capabilities as "permissions" and others as "authorities".  Both
grant rights.  How much mechanism seems to me a pretty
minor point - a distinction more quantitative than qualitative
as the emphasis in "Paradigm Regained" seems to claim.

Perhaps I'm still missing some essential point?

--Jed http://www.webstart.com/jed/ 



More information about the cap-talk mailing list