[cap-talk] [e-lang] File API taming
Stiegler, Marc D
marc.d.stiegler at hp.com
Thu Apr 9 19:46:22 EDT 2009
I am happy with this, given that I am sure that where you said,
"MarcS mentioned that it is unlikely for files to contain
You really meant,
"it is unlikely for file *paths* to contain secret information."
> -----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 --
> 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:
> 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
> Modules proposal of ServerJS:
> 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 A.B. Awad, Palo Alto, CA
More information about the cap-talk