GNOME.org
 

Re: [apparmor] Fwd: Initial ideas on portals for file access

Hello,


The xdg-app stuff for non-sandboxed apps is functioning pretty well
now, and even if its not 100% there yet its time to start looking at
making sandboxed application integrate with the system, the so called
"portals".

I've been thinking a bit about file access in sandboxed apps. There
are all sorts of files of course, some are the executables and data
files require for the app to work, and others are internal things like
save games and databases. These are really not all that hard, we
already have the readonly files in the app, and per-app writable
storage for internal files. The more interesting part is instead what
I'd call documents. These are files that the user is aware of and that
can be used by multiple applications. Typical examples of such files
are images, videos, text files, audio files, office documents, pdf
files.

There are a few ways such documents could be used by sandboxed
applications:

* Application silos

  All documents are owned by a particular app, sharing between
  applications is a copy operation. This is the model that iOS uses
  mostly. Its simple (already works in xdg-app essentially) and
  very safe.

* Allow app access to parts of $HOME

  For instance, you could have libreoffice have access to ~/Documents
  only. This is pretty limiting and not particularly safe, but it is
  easy to implement. This is similar to the android model, where apps
  that read shared files request the permissions to read your storage,
  and then get full access.


I think this is actually safe and useful for some classification of
apps. For example, your music application needs to constantly
reorganize and write metadata to files in the music folder. An
open-file-dialog is simply insane to consider in this situation.

The example you gave is certainly not, though. Luckily the dialogs you
flesh out work quite well in this case.

It could also work for "trusted apps" in the Pictures and Videos case,
but not for all applications because those folders often contain
sensitive photos or videos (e.g. private photos of somebody's family).



* Allow application access to files after interactive operation

  [snip]

Here are some available operations:

Open() - open document dialog, then optional download dialog
  Input: document type filter
  Output: A cookie
  Permissions granted:
    Allow reading the current version forever
    Allow reading future versions forever (maybe?)
    Allow getting file metadata
    These permissions affect only this app, other (sandboxed) apps have
      no access, so you can't pass on the cookie


Why no ro file descriptor in this case? As the other reply said,
refreshing the view once the file changes is a necessary
non-interactive feature.



SaveAs() - save-as dialog, then optional upload dialog
  Input: Initial title (can be used as filename)
  Output: A cookie
          A fd to write the file data to
          A way to set preview and metadata on the new file
  Permissions granted:
    Allow Save() without UI until a new version of the document
    Allow reading the file until a new version of the document

Save() - save new version to existing cookie, optional upload dialog
  Input: Cookie
  Output: Shows dialog if not allowed:
             No auth at all: "app foo wants to save..."
             Auth on previous version: "The file has changed since last
              time, do you still want to save"
          Way to write the data as in SaveAs()
  Permissions granted:
    Allow save and read of the new versions (until new version)

We would also have to make up some new kind of url scheme so that we
can persist these cookies to files, and so that we can pass then to
apps when we open files (i.e. when you click on a file in the file
manager).

There are some weaknesses i see here:

* The database for cookies risk growing forever, as its generally
  hard to know how to revoke some permission.


Perhaps implement a Close() API?


* In the save operation, I can't think of a good way to revoke access
  to the file once the app has finished writing and we're about to
  rename it over the old file. This means an app can modify a file
  that some other app is reading.


Double copy? Copy to an even more ephemeral location right before
showing the save dialog then copy that file to the original location
after the dialog gives permission.


* In wayland we don't have a great way to "parent" dialogs between
  client, so we can't make the file selector seem to be owned by
  the window that requested the file operation without some form
  of compositor help.


These dialogs have privelege; perhaps it is a good idea to make that
clear by making them screen modal and not just app modal? If not, then
as you said it would be pretty easy I guess to make it part of the
compositor API.

My final concern is applications that like to close, then reopen while
keeping all of their documents open and ready to go. One such example
is scratch [1], which autosaves files (i.e. without a dialog) and then
reopens them rw when the application is reopened. Will there be
something like an open-with-cookie API where all you need to do is
pass the cookie saying you had permission once and then just get an fd
without any dialogs coming up? Because if our users open up scratch
and see ten open file dialogs, one for each tab, that would not be
acceptable.


Anyway, this can be fleshed out more, but I'd love to hear some feedback
on this first.


This is really similar to what I have been talking about with
elementary folks (priveleged open default app for uri dbus service)
[2] and I am really excited about what you have here. One thing that I
think is important and this gets very right is not locking onto any
specific technologies. I can use this model with xdg-app, AppArmor,
SELinux, etc. and it seems like it would not need any adjustment.

[1] https://launchpad.net/scratch
[2] https://bugs.launchpad.net/elementaryos/+bug/1395531

Cheers,
--
Cameron Norman
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]