GNOME.org
 

Re: Initial ideas on portals for file access

On tor, 2015-03-12 at 18:26 +0100, Bastien Nocera wrote:

On Fri, 2015-03-06 at 21:34 +0100, Alexander Larsson wrote:


So, what do we want to do here? I don't think the application silo 
model is a good fit, because its very unlike how desktop Linux works 
(users file are stored in $HOME), and we would be fighting both 
users and existing apps making this work. We could allow partial 
HOME access to some very trusted apps, but that doesn't really 
strikes me as a proper sandbox solution.

In my opinion the last model is the one we need to focus on. The 
question is what kind of implicit permissions are we talking
about. For example, in the case of an open file dialog, here are 
some permissions that could be granted to the app:

 * Ability to read file contents (clearly ok)
 * Access to an actual file descriptor for the file
 * Access to the same file at a later time (how much later?)


How do you tell that it's the "same file"? It has the same path? How 
would you end up pruning your whitelist of allowed apps for each path?


My mail was meant to be pretty abstract/highlevel, and as such handwaved
over things like this. But, I think the most reasonable implementation
of this (in terms of both what is technically possible and what the user
would understand it to mean) is that "same file" means same
pathname/url. I.e. if you saved a new revision its the "same" document,
but if you "save as" its a new one.

We could have some kind of tracking of moves and try to keep the file be
"the same" if you e.g. moved a file or renamed a parent directory.
However, that is technically quite complicated and costly, and it is
dubious in terms of whether the user actually meant for the file to be
"the same" in the above sense.


 * Access to a new version of the file at the same place
 * Ability to replace the file with a new version
 * Access other files in the same location (say video subtitles)


That sounds iffy. It would be better if the application calling the 
file chooser could ask for certain annex files, and the user could see 
that those files are related.


I'm merely bringing up the requirements here, not saying we should allow
this. I agree that we shouldn't just allow this with no user feedback,
but on the other hand I can't really see a understandable UI that would
allow such annex files. This is just a hard to solve problem.


 * Knowledge about the file (filename, mimetype, mtime, etc)
 * Knowledge about the file environment (pathname, type of share, 
etc)
 * Ability to persist the file reference for later in e.g. "recent
files"
   (across app restart, and/or system restarts)
 * Ability to pass the cookie to another app

I don't think all of these are should be granted, but some
should. Clearly the open call has to returns some kind of (probably 
persistent) opaque cookie that refers to the file and has app
permission stored on it.


Michael mentioned the "save" use case, I'll mention the Camera 
application use case. I captured a screenshot/webcam/camera picture 
which will get stored in the "photos" store. I'd like to pass that 
picture to another application to get modified (say, GIMP) and have 
that application send it back when done.

Passing the same cookie as the original application will make it 
difficult to revoke the photo touchup application's permissions on 
that photo.


Its not necessarily difficult. It all depends on how the permissions
work. We could easily allow for the camera app to grant transient
permissions to the other application, and then revoke it. Or, we could
have the broker handle the cooperation and the touchup app not accessing
the real file, like you propose.

What would be nice though is if these two cases:
 * opening a photo in the file manager with the touchup app, granting
   access to that one file
 * Having the camera app chain out to the touchup app to allow
   touching up a photo we just took
were implemented with the same APIs to read/write the file inside the
touchup app.


I could imagine whatever daemon running in the background acting as 
the broker for those apps.

                   Camera app (through user)
- I have this photo, I'd like to pass it to another app to get modified
                   Daemon
- Sure, there's your list of apps
                   Camera app (through user)
- This one, here's a read-only handle for the image
                   Photo touch-up app
- Here's some kittens and and bold text to put on top. All done, 
here's another read-only handle for another image, and the handle for 
the original image.
                   Daemon
- Let me check whether that matches. Yep, still ok with Camera app. 
Camera app, there's your modified image corresponding to this one you 
asked to modify.
                   Camera app
- Cheers. Storing that here. Or overwriting the original. What do you 
say user?


So, this seems to me like you want to be able to grant (transient)
permissions to read/write a file to another app, and then redirect any
updates to the side so that the "sending" app can do whatever it wants
with the new one. Its kinda like a "grant copy-on-write rights"
operation.


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



I think that the file selection window should be owned by the 
compositor/shell, and should be unspoofable. It's a permission 
granting job after all. It could be populated by the application in 
some limited way for internal "sharing".


I kind of agree, but "unspoofable" in this context generally means some
desktop level modal operation, and that is a pain in the ass for the
user. While that is up you can't do anything else in parallel, and you
can't see much info from other apps. How could we do something
"unspoofable" and yet be less in-your-face?


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


The Open/Save dialogues are kind of a special case of "Sharing". I 
would expect a way to open a URL, a Photo from the Photo library, etc. 
to be one of 2 mechanisms, the pull one.

I think that the majority of interactions would instead be push ones. 
Send this video file in my Mail to the video player, share the URL of 
this web page to Twitter, open this PDF from the web to my Documents.

This doesn't need cookies, at worst a receipt that the data has been 
received on the other end if you want to "move" it from one app to the 
other.


It doesn't really need cookies, true. It could just stream the data back
and forth without any reference to some underlying document file.
However, if we allowed some form of cookie-based access to a file for
this usecase that would probably be helpful. First of all, the sending
app doesn't need any code to stream the data, it just grants right to a
file it already has. Secondly, on the recieving side you can use the
same APIs/code that you have when reading a document opened in some
other way, also you can do things like seek and do partial reads rather
than a full copy (in case the file was e.g. a large video).

So, the "cookie" is not all that interesting per se. But we want some
kind of broker API here that is expressive enough that we can do all
these things, while still protecting the boundaries between these apps.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a shy misogynist jungle king in a wheelchair. She's a chain-smoking 
snooty schoolgirl who hides her beauty behind a pair of thick-framed 
spectacles. They fight crime!
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]