[e-lang] File API taming

[Sam Mason]

On Thu, Mar 19, 2009 at 05:24:52PM -0700, ihab.awad at gmail.com wrote:
> On Thu, Mar 19, 2009 at 5:17 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
> > Most modern OSes do something based on some notion of file type. Generally
> > they associate a file with an application so double clicking the file opens
> > the application.
> 
> So in the brave new world I propose, something with access to the
> parent directory of the file, and thus able to determine what the name
> of the file is, would have to make the association between file and
> app. Once launched, the app would not know -- nor need to know -- what
> the file is called.

Extrapolating a bit to what would appear to be an awkward case; how
would a program handle files that have references out to other files?
The most widely known example I'd know would be an HTML document and
the images, CSS and other miscellanea it happens to refer to.  Or even
further to other file formats I've come across where you have a "data"
file that contains unstructured data and a "header" file that defines
the structure of the data.  These files were assumed to have the same
name, with the data file ending in ".bin" and the header ".hdr".

I'm struggling to think how programs that have to handle these sorts of
issues would cope if all they received was a capability to the file to
be "opened".  The bin/hdr problem seems soluble by having the program
supply some code whose purpose it is to identify other files required
to open the selected file.  It could be given read-only access to the
(local?) filesystem and the path of the file to be opened, it would
return a list of paths needed to open and the calling program would
receive capabilities to these files after the user had vetoed them.

This seems fragile and would open a covert channel in the presence of
any non-determinism.  I'm assuming here that this helper code would be
registered at install time and would have no mutable state associated.
The helper could generate a random number, open a known (at installation
time) sensitive file and encode in the selection of files returned
some subset of the information in the file as determined by the random
number.  The main program could slowly recover the sensitive file from
the number of extra files received, about 3bits of information per
invocation seems easy.  If the helper had time it could also choose the
files to return so that some function of their contents could divulge
the secret, thus widening the channel significantly.  This also doesn't
seem like a particularly workable solution; an HTML file with Javascript
inside can open arbitrary files at runtime.  Nor does this seem very
safe; for the user to veto the list it would need to be displayed and
the user capable of making a decision as to whether these files are OK
or not.

I feel like I'm missing something obvious but can't think what.

-- 
  Sam  http://samason.me.uk/