[cap-talk] Abstractions that subsume capabilities

Kevin Reid kpreid at mac.com
Sun Mar 9 12:34:15 EDT 2008


On Mar 9, 2008, at 11:26, Sandro Magi wrote:

> Both capabilities and RT techniques impose restrictions on the use  
> of effects which affect the "world", ie. via devices. In Haskell,  
> this distinction is not very fine-grained at the moment, as most  
> effects simply live in the "IO" monad, but there is no reason why  
> these effects couldn't be made more fine-grained, ie. IO => DelDir,  
> SendPacket, etc.


That type of subdivision is not sufficient, since it does not readily  
permit specifying *which* directory is deleted, or *where* the packet  
is sent. It expresses an essentially static access policy.

The way I have thought of doing a capability version of Haskell is to  
leave the IO monad alone, but make its *operators* require non-global  
authorities. That is, instead of the current

   type FilePath = String
   readFile :: FilePath -> IO String
   hPrint :: Show a => Handle -> a -> IO ()
   stdout :: Handle

   main = do
     s <- readFile "/etc/passwd"
     hPrint stdout s

, access to files and standard output would be explicitly passed, and  
start out as an argument to 'main' much like the privilegedScope in E:

   data FilePath = ...unexported constructor or opaque functions...
   pathToFile :: World -> String -> FilePath
   stdout :: World -> Handle

   main world = do
     let f = pathToFile world "/etc/passwd"
     s <- readFile f
     hPrint (stdout world) s

(I'm not sure if pathToFile ought to be ... -> IO String.)

This approach so far isn't sufficient to support substitutability  
(for e.g. membranes or test frameworks), unless FilePath is a record- 
of-functions or replaced with a typeclass, but it would require the  
least modification to existing Haskell programs.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>




More information about the cap-talk mailing list