Re: Initial ideas on portals for file access
- From: Alexander Larsson <alexl redhat com>
- To: Bastien Nocera <hadess hadess net>
- Cc: gnome-os-list gnome org
- Subject: Re: Initial ideas on portals for file access
- Date: Fri, 13 Mar 2015 13:24:55 +0100
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]