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 _______________________________________________ gnome-os-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-os-list
