Re: Initial ideas on portals for file access



On fre, 2015-03-13 at 12:25 +0100, Bastien Nocera wrote:
On Fri, 2015-03-13 at 10:08 +0100, Alexander Larsson wrote:

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.

Right. But I would probably expect an application being granted access 
to, say, a video, doesn't suddenly stop being able to access it once 
I've fixed a typo in the name.

Well, isn't that already "broken". I mean, if you rename a file right
now, all references to it (in say a recent files, or as a by-pathname
reference in some other document) would fail to load the file. The way
you'd fix this is to report the load error and then open up an open
dialog to re-select the file, which will grant you the privs.

I mean, technically if we track the file other than via the pathname
(such as with some document cookie) we could detect the rename and
handle that. It seems like that is gonna be technically hard though.

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

For the video subtitles case, you could pass a list of mime-types that 
the chooser could "attach" along with the video file. I'm not sure how 
we could advertise that additional files are getting selected along 
with the video file though.

Mime types + some kind of rewrite rules based on the selected filename.
But, how would you tell the user? And how would you verify that the
rules are safe? Maybe if we only allow same basename + a list of extra
extensions it would be safe enough.

I think a bigger problem might be with document types where the assets 
aren't in the same file. For example, again with video, a Pitivi 
project would have a project file (which you'd open), and assets in 
the same directory.

Yeah, I'm not sure how to best solve that. One option is for pitivi to
have all files imported into the per-app data, like the app silo model.
That is kind of a large change though, and the video snippets imported
could easily be very large.

How common are these types of apps though? Maybe its good enough to say
that they'd have to be given full access to the Videos directory.

My point being that using solely a cookie might not be good enough. It 
might be that the broker daemon needs to key off cookie + app 
identifier, not just cookie.

Yeah, the permissions would be based on the app identifier. I didn't
really list this as input in anything because that will be implicitly
given as argument to the dbus service. I.e. we will be reading the app
id from the cgroup via the dbus socket getpeercreds (or similar for
kdbus).

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl redhat com            alexander larsson gmail com 
He's a bookish soccer-playing paramedic with a winning smile and a way 
with the ladies. She's a man-hating Buddhist mechanic with a 
flame-thrower. They fight crime! 



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]