[cap-talk] Applications for a capability platform - PLASH discussion

[Jonathan S. Shapiro]

On Fri, 2008-02-29 at 14:44 -0800, Jed Donnelley wrote:
> On 2/29/2008 9:49 AM, Jonathan S. Shapiro wrote:
> > On Fri, 2008-02-29 at 09:27 -0800, Jed Donnelley wrote:
> >> At 06:18 AM 2/29/2008, Jonathan S. Shapiro wrote:
> > 
> > The net effect of this is that the application is oblivious to the fact
> > that it runs within a capability environment, and no "caplib" is
> > required. A major point of PLASH is that application re-engineering is
> > not required.
> 
> How do I run "chmod" under PLASH?

Toby has used it, so I suspect he is better able to answer this than I
am, but here is my guess. Chmod behaves in the usual way, but its effect
does not survive the exit of the application unless the PLASH power box
agrees. Since the name space visible to the application is not shared
with any other application, the presence of a chmod'd file doesn't
hazard third-party applications.

The more interesting case would be chmod involving setuid. I suspect
that this is simply rejected, or that allowable setuid/setgid is
configurable through the power box, but I do not know.

> PLASH would seem to provide
> no interface to the underlying capability infrastructure, specifically
> for delegation (sharing) of authority.  That is where I was suggesting
> that something like "caplib" could be needed - if we had enough
> of an underlying capability infrastructure to make it worthwhile.
> At least capability manipulation could have an agreed upon API.

I suspect the mechanism for this in PLASH would be some variant of
link(2), wherein the application first constructs the object in its
private name space and then links it into a public name space subject to
consent of the power box. Recall that PLASH is limited to the set of
objects supported by UNIX (basically files and directories), so this
would seem to be the "natural" (least unnatural?) method of publication.

> Hmmm.  What about the issue of "third party" software?  It has
> generally been when significant amounts of software started being
> developed for a platform (e.g. the PC, Mac, Unix) that the issue
> of the API becomes significant.  Are the software developers
> all working still to support a single vendor at this point?

To date, there exists essentially zero third-party software for cell
phones. What there is generally turns out to be replacements for things
like the browser or the email reader that comply more fully with
external standards.

I am aware that exceptions to this statement exist. By "zero", I mean
"zero applications having measurable market share".

Ignoring javascript, All of the software that you will ever use on your
cell phone ships with the phone, and all of the data manipulated by
those applications divides neatly into:

  1. Externally stored data in a standard format or accessed through
     a standard protocol.

  2. Externally stored, non-migratable data accessed through a
     proprietary and undisclosed protocol. Some cell phone email
     accounts meet this description (and are therefore useless to me).

  3. Locally stored, non-migratable data in a proprietary format.

By "non-migratable", I mean that you need to go through sufficient
contortions that nobody bothers. There do exist address book transfer
programs, but I don't know anybody who has actually bought one.

All of the cell phone "applications" are being delivered by WAP or by
HTML, mainly because the vendors failed to implement *any* internal
security mechanisms on these platforms, and cannot accept the risks
associated with wide access to the development SDKs. Also because the
phone vendors are trying to get a chunk of change from the developer,
and for most developers it just hasn't been worth the bother.

Things like OpenMoku may start to slowly tip the balance over time.
Perhaps too early to tell.

> While the above may not be GNU applications, I agree with Toby that:
> 
> On 2/29/2008 10:03 AM, Toby Murray (in response to above) wrote:
>  > These applications all depend on the standard POSIX interfaces.

On cell phones this is not true, because to first order no POSIX cell
phones exist.

As to your comment about "capabilities visible at the API", I think
that's silly. The driving issue is capabilities visible at the UI. Find
me an application where that is well-motivated in the eyes of my Dad and
then we can discuss whether or not a cap manipulation library is called
for.


shap


shap