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