Individual file access

[Norman Feske]

Hi Ben,

On 07.06.2017 05:05, Nobody III wrote:
> To start off, I'm planning on building a component that handles file
> open/save requests for other components, primarily graphical
> applications. My plan is to use a qt5 QFileDialog for the user to select
> one or more files, then modify the vfs server's configuration to attach
> the selected file(s) to the component's filesystem.
> 
> To attach individual files to a component's filesystem, it seems like I
> should write a server-side link vfs plugin. The plugin would be like a
> symlink, but would transparently resolve the link within the vfs server,
> providing access to otherwise inaccessible files. Is this possible? If
> so, can you give me some tips on how to implement it?

I like your idea but would pick a slightly different direction.

Let me illustrate the scenario that I would suggest:

                       ------------------
                      | File picker (Qt) |
                       ------------------
                              ^
                              |
      -----              -----------               -------------
     | App | ---uses--> | fs filter | ---uses---> | file system |
      -----              -----------               -------------

The application (App) does not talk directly to a file-system server but
has a file-system session to a filter component. To open a file, the app
would generate an arbitrary file name 'a' and open the file 'a' at the
filter. File 'a' does not actually exist though. The filter's job is to
provide a virtual file 'a' such that read operations are redirected to a
real file at the file system. In contrast to the app, the filter has
access to the real file system. To determine the real file to be exposed
to the app as 'a', the filter spawns a file-picker component as a child.
When the file picker requests a file-system session from its parent (the
filter), the filter hands out a read-only session to the real file
system. Using this session, the file picker can present the file-system
content via a QFileDialog. Once the user selects a file, the file picker
informs the filter via a report submitted to a 'Report' session. Now,
the filter knows that the virtual file 'a' corresponds to the selected
real file and can forward read operations of the app to the real file
system.

The case for writing would be similar.

This approach has the following interesting properties:

* The app does not need to know any name of the real files stored in
  the file system.

* The filter is transparent to existing applications that open a file
  given as argument. For example, mupdf would request always the same
  pdf. But thanks to the filter, it would open the pdf selected by the
  user. The real file name remains hidden.

* By separating the filter from the file picker, the complex Qt code
  does not need to be ultimately trusted. It has no write access to
  the file system. Even though it could read data, it has no way to
  leak it. In contrast, the filter has full read/write access to the
  file system. So it must be trusted. But in contrast to the file
  picker, its complexity is very low. Furthermore, the design in
  principle supports alternative implementations of the file picker
  without the need to modify the filter.

* The scenario does not need to reconfigure any components. In
  particular, there is no need for the file system to trust the filter.
  From the file system's perspective, the filter is just a regular
  client.

* The file picker could be killed each time after picking a file.

* If the app supports the selection of multiple files, it could open
  a directory instead of a file.

* The file name invented by the app may contain hints about the file
  types the app supports. This could be taken into account by the file
  picker (e.g., showing only PDF files if the app requested a file
  called 'a.pdf').

* The filter could remember the association of the virtual files with
  real files even after the app has closed a file. If the app saves a
  file with a name that was previously opened, it could open the already
  known real file instead of presenting a file picker. (thereby
  covering the distinction between the "save" vs. "save as" use cases)

Cheers
Norman

-- 
Dr.-Ing. Norman Feske
Genode Labs

http://www.genode-labs.com · http://genode.org

Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth