[cap-talk] object-oriented-security.org

[Kevin Reid]

On Mar 5, 2010, at 15:55, Kenton Varda wrote:

> On Fri, Mar 5, 2010 at 9:21 AM, David Wagner <daw at cs.berkeley.edu>  
> wrote:
> Object capabilities are often understood to include the following:
>
>  * A design practice of building abstractions with encapsulation.
>  * Programming on a platform (e.g., language, OS) that is free of
>   ambient authority.
>  * Ensuring that access to all security-relevant resources can be
>   done only via unforgeable references (capabilities).
>
> My point here is that your latter two points (which seem like the  
> same point to me) really boil down, in OO terms, to "don't use  
> singletons".  As it turns out, there is now widespread agreement  
> among OO programmers that singletons should not be used.  The  
> problem is that most platform libraries (designed before people  
> understood the dangers of singletons) still expose the filesystem  
> and other resources as singletons.

[Quick response; take all blanket assertions here with a grain of salt]

Access to “the filesystem of this machine”, or rather let's say to  
open(), *is* inherently a singleton; similarly “Internet access from  
this machine”, “the free memory of this machine”, etc. In order to not  
have singletons here, you have to add some type of subdivision (which  
may be non-natural to the platform) such as “access to the subtree of  
the filesystem rooted at this path”.

On the other hand, these *are* design mistakes:

   * having a (public) *type* for that singleton, such that it is not
     possible to substitute a different but equivalent-interface
     authority because it would have the wrong type.

   * having that singleton be accessed “globally” from everywhere in
     the program (e.g. passing around filename strings instead of file
     objects).

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>