Re: [e-lang] File API taming

I would guess that you would suffer no real loss of functionality, but would make the code enough simpler to be preferable for a security review, if you simply disallowed ".." completely, i.e., disallow 

>   d.resolve('a/b/../c');

I have worked for years with the E file api without missing the "..", which I believe is completely forbidden in E.

The reason I urge this simplification is that, as we have all found more than once now, the manipulation of strings that are representing authority is one of the riskiest things we do. It usually creates a great upwelling of opportunity for introduction of vulnerability. Keep it as simple as possible for survival's sake.

The thing I have occasionally found myself wishing I had, which might be a good convenience method (though you can live without it), is getParent(root, file), which would give you the parent of "file" if that parent were in the subtree below "root". Basically, giving root to getParent demonstrates that you have the authority, you're just trying to figure out which of the authorities you have is the right one to wield. This would serve the same purpose as the transferFocus([panelroots], panel) method we added to E for the windowing system, which allows you to move the focus from where it currently is to a new place, as long as you can demonstrate that you have authority over both the current focus location and the target focus location. Please note that the getParent function should be supp
 lied by a trusted third party (the api itself typically), it cannot be put as a method on the file object, lest the file object be a trick file object interested in stealing the other autho!
 rity that is involved.

--marcs

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On Behalf Of 
> [email protected]
> Sent: Thursday, April 09, 2009 10:35 PM
> To: Discussion of E and other capability languages
> Cc: General discussions concerning capability systems.
> Subject: Re: [cap-talk] [e-lang] File API taming
> 
> I should clarify some vagueness that was caught by David Wagner --
> 
> 
> On Thu, Apr 9, 2009 at 4:34 PM, <[email protected]> wrote:
> 
> 
> 	* Files provide a "getPath()" up to the closest 
> makeOpaque()-ed directory; and
> 	
> 	* Each sandbox gets a reference to a (usually -- but 
> not always -- makeOpaque()-ed) reference to a directory that 
> serves as its "chroot()-ed jail".
> 	
> 
> 
> One more criterion is that no directory (makeOpaque()-ed or 
> not) can resolves a ".." path that traverses past its own 
> level. So, for directory 'd', the following work --
> 
>   d.resolve('foo/bar');
>   d.resolve('baz');
>   d.resolve('a/b/../c');
> 
> but not --
> 
>   d.resolve('..');
>   d.resolve('a/b/../../..');
> 
> 
> Ihab
> 
> --
> Ihab A.B. Awad, Palo Alto, CA
> 
>