rexec.py unuseable

[Luke Kenneth Casson Leighton]

On Tue, Dec 16, 2003 at 07:13:21AM -0800, Michael Chermside wrote:

> Suppose that had some code which had an object representing a
> directory, with a method "open(filename, mode='r')" that opened 
> files in the directory. Given this object, you could imagine 
> constructing new objects with more limited capabilities. 

 yep.  in a very simple manner, with capabilities lists.

> For 
> instance, you might create a readOnlyDirectory object which had
> a method "open(filename)" that didn't allow specifying the mode
> as anything but 'r'. Or you might open a file and then pass a
> file object with "read()", "write()", "seek()", and other such
> methods, which would only access that file.

 this could be achieved very simply by setting a CCL with
 "deny everything" permissions on an object that, ordinarily,
 had a full set of functions with NO restrictions, but leaving
 read() alone.

 _and_ also, importantly, adding a CCL onto the __builtins__ etc
 as already discussed to restrict bypassing.


> So _IF_ the only way to access files were through this object (and
> that's a BIG if), then you could imagine a world where HAVING and
> object was equivalent to being able to do something. If a bit of
> code had access to a read-only-file object then it could read that
> file, but couldn't write to it, or do anything else with the file 
> system unless it ALSO had access to some OTHER objects. 

 yep.

> That's
> capabilities... and it would work for most kinds of restricted
> resources, not just the file system. The key idea is that HAVING
> a pointer to the object is equivalent to having the permission to
> USE that object, and whatever it provides access to.

 ah... that's where you and i differ, based on my experience of
 ACLs in NT.

 i envisage a separate "execute" permission from a "read" and "write"
 permission, a bit like directory permissions on a POSIX filesystem.

 under such a scheme where "execute" capability permission exists
 as well as "read" and "write", simply having access to an object
 does NOT guarantee you any rights to CALL that object, because if
 it doesn't have "execute" permission you can't execute [viz, call]
 it!

 ... but what you _can_ do is pass that object to another function which
 _does_ have execute permissions.

 how the hell is _that_ achieved, i hear you say???

 well imagine a CCL as follows:

 [('totally_restricted_function, 'DENY', 'All permissions'),
  ('slightly_less_restricted_function', 'ALLOW', 'execute and read')]

 and this CCL is applied to  the above-mentioned readOnlyDirectory
 object.

 if totally_restricted_function() calls
 slightly_less_restricted_function(), passing a readOnlyDirectory object
 to it, then according to the CCL above, ONLY
 slightly_less_restricted_function() may call functions in that
 object.

 cute, huh?

 l.