[e-lang] simple question

[Marc Stiegler]

Matej Kosik wrote:
> Kevin Reid wrote:
>> On Aug 15, 2006, at 12:49, Matej Kosik wrote:
>>
>> .e programs exist solely to bridge between the capability world and  
>> current OSes.

I would have said, it is a bridge between the underlying world of 
primitive hardware authorities and the capability world. If we imagine a 
computer for which the OS has been written in E, the kernel of that OS 
would be embodied in .e files.

> I am not sure how to work with CapDesk (I've launched it; I saw some
> directories; I have tried to "install" the capEdit.capplet but it failed
> with the following message:
> 
>     starting run prep
>     made scope 2
> 
>     # value: <capEditCapletAuthor>
>     shown
>     about to get requestsTree
>     got requestsTree
>     requests retrieval failed: problem: Prefix doesn't match: visit
> )

Markm, this looks like the problem I was having with the current public 
release. Matej, try backing up a couple of E releases and trying it (and 
markm, consider unveiling the later not-yet-release).

> 
> E programs cannot be run in safeMode without CapDesk? For example:
> running a E program and giving it (at startup) capability to some
> object...which, for example, enables it to write 10 lines to some file.
> Or something similar. (just a proposal)

Your proposed example sounds a similar to the sash powerbox, which I'll 
describe later in this reply.

E programs, by definition, have one .e file that acts as the "main". 
CapDesk includes within it a "powerbox" that manages authorities for 
caplets launched in the CapDesk framework (each caplet launch gets its 
own powerbox). The CapLauncher (currently broken, on my list to fix), 
included in the E distribution, is an extraction of the powerbox system 
from CapDesk (CapDesk includes other things, notably a file explorer). 
If you trust the small CapLauncher, you can safely launch caplets 
"directly" off the underlying OS. The CapLauncher is also a .e program.

Powerboxes can be designed (and should be designed) to be small, easily 
widely inspected, and reusable for a broad family of applications. The 
CapDesk powerbox was designed (and skeletally implemented) to launch 
just about any kind of gui-based app that you might think of running on 
a traditional desktop.

The CapDesk powerbox is a fancy beast, even in skeletal form. It may be 
easier to understand the relationship of the .e file (which in good 
usage is shaped like a powerbox) to the .emaker by looking at Emily, a 
capability based version of OCaml, at

http://www.skyhunter.com/marcs/emily.pdf (there should be a tech report 
published by HP in the next 2 weeks, "How Emily tamed the Caml", that is 
a better reference).

For Emily, as a demo I built a very simple powerbox, called "sash", that 
fits on a single powerpoint slide. This powerbox, which like CapLauncher 
acts as the "main" for a broad class of applications, was designed to 
enable the creation of safe bash commands. Bash commands represent a 
large family of applications, this one-slide powerbox is good enough to 
support an interestingly large subset of those commands. If you trust 
the sash powerbox, you can safely run all the different apps designed to 
use sash as the "main".

Whereas in E, the app launcher and app body are distinguished by the 
file suffix (.e versus .emaker), in Emily they are distinguished by 
location: the powerbox components are placed in one folder, the app 
sources are placed in a different folder, and the Emily compiler 
compiles them in different scopes (the powerbox is compiled in the Emily 
equivalent of a privileged scope, the program body is compiled in a safe 
scope).

Another item on my task list is to replace the terrible powerbox example 
in "E in a Walnut" with an E version of sash. I believe sash is a good 
tool for teaching these principles; ironically, since developing it I 
have repeatedly found it to be useful in practice, having now used sash 
and emily to write a number of text-crunching bash commands, not because 
I wanted to show off the tool, or because I feared I would write 
malicious code to attack myself, but just because it was the quickest 
and easiest way to get the job done. It had some payoff for debugging, 
too: since my text-crunchers were crunching whole directories, it was 
comforting to know that, because of the powerbox, the first broken 
version of the app would not run off and hammer my drive root :-)

Powerboxes are more general than being the objects that lie between OSes 
and applications. The powerbox pattern is appropriately placed as the 
intermediary on any complex trust boundary, where the authorities 
granted across the boundary may change over time or per invocation. We 
built a powerbox at the boundary between the DarpaBrowser and the 
malicious renderer for example, which is another place where the object 
on one side of the boundary (the darpabrowser) has large authorities, 
only a small changing part of which should be granted to the renderer 
(the grant changes every time you switch pages). However, the boundary 
between OS and application is one of the trust boundaries that most 
obviously screams out for such a mechanism :-)

--marcs