[cap-talk] POLA and Mungi / Iguana style APIs

[Bill Frantz]

On 5/19/05, daw at cs.berkeley.edu (David Wagner) wrote:

>Bill Frantz writes:
>>This approach allows for the separation of authority between the
>>compiler installer, the person who calls the factoryMaker, and the
>>compiler user, who calls the compilerFactory.  Because the compiler
>>instance is discarded after each use, there is no danger that
>>capabilities passed on one call may erroneously be used on another call.
>
>Interesting point.  Can I try my own version, and can you critique it?
>
>    class Compiler {
>        private File myBillingFile;
>        Compiler(File f) {
>            myBillingFile = f;
>        }
>        void compile(File src, File obj) {
>            byte[] objdata = compileString(src.readAll());
>            obj.write(objdata);
>            myBillingFile.write(... billing record ...);
>        }
>        byte[] compileString(String s) { ... do all the real work ... }
>    }
>
>    class CompilerMaker {
>        private File myBillingFile;
>        CompilerMaker(File f) {
>            myBillingFile = f;
>        }
>        Compiler compilerMaker() {
>            return new Compiler(myBillingFile);
>        }
>    }
>
>Does this work as effectively as your proposal?

I think this should be as effective as my proposal.  Both our proposals have the flaw that the returned Compiler can be used for more than one execution of the compiler.  That is not an accounting problem, as they write to the accounting file for each execution, but rather a potential capability transfer between executions problem.


>I'm trying to figure out what the cleanest way to do this in real Java
>would be.  In particular, I wasn't sure exactly how to implement your
>Factory; is the above faithful to what you had in mind?  Also, I prefer
>to use strictly typed interfaces (no Object[] where a better type is
>available).

In my example, I was trying to duplicate (more or less, with a lot left out), the function of the KeyKOS Factory.  Since there is only one factoryMaker in KeyKOS, the use of Object[] for the array of capabilities each instance will be endowed with after creation matches that model.  (The KeyKOS Factory uses a KID <http://www.cis.upenn.edu/~KeyKOS/agorics/KeyKos/Gnosis/79.html>, the creation of which is somewhat closely held.


>Note that the above still has a deficiency, because the billing file
>object is shared across Compilers, and this provides a channel between
>Compiler instances.  This might create accidental bugs, or allow malicious
>passing of capabilities from one call to another.

Yes, but I think that deficiency is inherent in the statement of the problem.  


>My first attempt had compilerMaker() use myBillingFile.clone() rather
>than myBillingFile, but this doesn't work in Java, since File.clone() is
>protected.  Note that this problem also seems to appear in your version.
>I think this problem would go away if our objects were stateless (e.g.,
>immutable).

By suitable restrictions on the type of the billing file object, we could prevent transfer of capabilities between instances.  Solutions which return a compiler object good for a limited number of compiles can completely eliminate these channels between instances, as well as eliminating the billing file as a way for the compiler to steal the source code.

---------------------------------------------------------------------
Bill Frantz        | The first thing you need   | Periwinkle 
(408)356-8506      | when using a perimeter     | 16345 Englewood Ave
www.pwpconsult.com | defense is a perimeter.    | Los Gatos, CA 95032