[cap-talk] [e-lang] File API taming

[Stiegler, Marc D]

I am happy with this, given that I am sure that where you said, 

"MarcS mentioned that it is unlikely for files to contain 
secret information." 

You really meant, 

"it is unlikely for file *paths* to contain secret information." 

:-)

--marcs

> -----Original Message-----
> From: cap-talk-bounces at mail.eros-os.org 
> [mailto:cap-talk-bounces at mail.eros-os.org] On Behalf Of 
> ihab.awad at gmail.com
> Sent: Thursday, April 09, 2009 4:34 PM
> To: Discussion of E and other capability languages
> Cc: General discussions concerning capability systems.
> Subject: Re: [cap-talk] [e-lang] File API taming
> 
> [ Responding to the last post, but really to the entire thread. ]
> 
> Thank you all for this wonderfully erudite discussion. I 
> spent quite a while just now reading over the entire thread. 
> I'll summarize the things I got out of it --
> 
> We have come to treat file "names" as intrinsic properties of 
> the file "nodes", while in fact they are properties of the 
> arcs from directories. Thus really, I would like my 
> filesystem to tell me that some given file is called --
> 
>   "Pepsodent Advertising Revenue Report"
> 
> and is known by the name --
> 
>   /home/ihab/docs/pepso/ads.doc
> 
> All modern document editors have a "Title" field. How many of 
> us fill it out completely as soon as we open a document? Show 
> of hands? ;) ... Right. We rely on the path to disambiguate. 
> As long as we continue to do this, I have to agree at least 
> to some extent with MarcS that we have no recourse but to 
> treat the path as -- if not essential information -- then at 
> least *helpful*.
> 
> At this point, I need to remind myself that I am talking 
> about taming a traditional filesystem. If we were building a 
> new persistent object system from scratch, then Kevin Reid's 
> remarks about building a "history" tracker to keep track of 
> objects and annotate them with context would apply, and I 
> think we should throw out all this mess we have now and start over.
> 
> MarcS mentioned Google Docs and Spreadsheets as an example of 
> something that builds its own naming scheme, more or less. 
> Actually, Google Docs indexes the "Title" of the document; 
> its internal identifiers are machine generated and cap-like. 
> For example, in my Google Docs, I have two documents titled 
> "Foo" right now:
> 
>   http://docs.google.com/Doc?id=dfgxb7gk_64g2czqgg6
>   http://docs.google.com/Doc?id=dfgxb7gk_639z5xfsfh
> 
> They both show up by their title, "Foo", in the UI. I don't 
> know what the product managers of Google Docs would say about 
> this, but if I were to channel them, I'd say, "This is Google 
> -- search!"
> 
> MarcS mentioned that it is unlikely for files to contain 
> secret information. Yes, for the common case that is true, 
> but. There are many of file names in proprietary server apps 
> that would be disastrous (or at least embarrassing :) if leaked.
> 
> David-Sarah's point about <DirectoryEntry> vs. <File> is a 
> good one. An equivalent suggestion is from MarcS, regarding 
> the ability to "makeOpaque()" a file, thus "orphaning" its 
> path in the directory hierarchy; essentially, a "chroot()". 
> Except David-Sarah's scheme is _prix fixe_ while MarcS's is 
> _a la carte_.
> 
> In the setting in which this problem is most urgent, we wish 
> to endow a JavaScript module sandbox, per the Securable 
> Modules proposal of ServerJS:
> 
>   https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
> 
> with some reference to *something*. Having read over this 
> thread, I think a pragmatic solution would be if:
> 
> * Files provide no "getParent()";
> 
> * 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".
> 
> Does that sound reasonable?
> 
> Ihab
> 
> --
> Ihab A.B. Awad, Palo Alto, CA
> 
>