VM-based powerbox system
A compromise system would be to run applications in a machine-level VM such as Xen, KVM or QEMU, and use a powerbox to delegate access to files by running a file synchroniser, as Polaris does.
This would be much heavier-weight than Plash. Would use more memory (no sharing), and take longer to start up (because kernel must boot). However some bulk IO, such as opening a lot of files, might be faster with Xen or KVM. The emulation would be more complete.
Options for granting access to files:
- File synchroniser:
- Use inotify to detect changes on both sides.
- Use rsync over ssh to copy files? It would have to work in both directions, so rsync may not be suitable. If the corresponding files on both sides are modified at the same time before being synchronised, give an error and halt synchronisation for that file.
- File attributes such as executable bit should not be copied.
- Use a custom filesystem in which files can appear selectively.
- Possible protocols: NFS, Samba, ssh (using FUSE sshfs).
- Implement custom server that can grant files selectively.
Powerbox implementation: Use D-Bus as a protocol, over ssh.
Advantages:
- Revoking access to files would be easy.
- Memory allocation and disc space usage can be controlled.
- Network access can be controlled.
Main hole is X11Security. Could reprioritise writing an X11 security proxy.
Questions
How can D-Bus be used remotely?
Tasks
- Write file synchroniser
- Write powerbox that receives requests via D-Bus and sets up synchronisations
- Create application launcher
- Create tool for setting up VM
Gtk file chooser hook:
Change existing LD_PRELOAD hook to use D-Bus
Write unit tests for Gtk with a mock powerbox requester
Split D-Bus-specific code in hook out into separate libpowerbox
- Create Debian package for libpowerbox
- Change Gtk directly (instead of LD_PRELOAD hack) to add hook via libpowerbox
- Add backends to libpowerbox:
- Plash object invocation (i.e. the original)
- Invoke a command line program (similar to powerbox-req program)