GNOME.org
 

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

On lör, 2015-03-07 at 09:56 -0800, Cameron Norman wrote:


  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.


Yeah.



* 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.


Yeah, this is a bit handwavy. The idea was that the cookie itself + read
permissions would allow you to at any time get such a readonly file
descriptor.


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?


There is an obvious GrantPermission()/DenyPermission() operation pair
here. But who would call it? When?


* 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.


Yeah. Thats the only approach i've figured out so far. Could be coupled
with some splice/sendfile action to avoid a copy to userspace, or even
reflink on btrfs. Still, not ideal... Maybe one could use a fuse
indirection layer.


* 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.


They don't have priviledge in the traditional sense. Everything is still
running as the user session, but yeah, there is *some* kind of
priviledge. That said, a screen modal dialog is kinda painful to use,
since you can't really multitask while that is up. We should really try
to limit the number of such dialogs.


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.


Yeah, if you have a cookie with permissions you should be able to do i/o
on it without there being dialogs.


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.


Open default app seems like another useful portal operation that we need
to look into. Everything moving towards dbus activatable desktop
application helps a bit I guess, but still we don't want to hand the
full list of installed desktop file to an app that just wants to launch
a file handler on a file.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a genetically engineered crooked messiah with a winning smile and a 
way with the ladies. She's a mentally unstable thirtysomething museum 
curator who don't take no shit from nobody. They fight crime!
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]