On lör, 2015-03-07 at 09:56 -0800, Cameron Norman wrote:
> > 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.
Yeah.
> >
> > * 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.
Yeah, this is a bit handwavy. The idea was that the cookie itself + read
permissions would allow you to at any time get such a readonly file
descriptor.
> > 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?
There is an obvious GrantPermission()/DenyPermission() operation pair
here. But who would call it? When?
> > * 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.
Yeah. Thats the only approach i've figured out so far. Could be coupled
with some splice/sendfile action to avoid a copy to userspace, or even
reflink on btrfs. Still, not ideal... Maybe one could use a fuse
indirection layer.
> > * 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.
They don't have priviledge in the traditional sense. Everything is still
running as the user session, but yeah, there is *some* kind of
priviledge. That said, a screen modal dialog is kinda painful to use,
since you can't really multitask while that is up. We should really try
to limit the number of such dialogs.
> 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.
Yeah, if you have a cookie with permissions you should be able to do i/o
on it without there being dialogs.
> > 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.
Open default app seems like another useful portal operation that we need
to look into. Everything moving towards dbus activatable desktop
application helps a bit I guess, but still we don't want to hand the
full list of installed desktop file to an app that just wants to launch
a file handler on a file.
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
[email protected] [email protected]
He's a genetically engineered crooked messiah with a winning smile and a
way with the ladies. She's a mentally unstable thirtysomething museum
curator who don't take no shit from nobody. They fight crime!
_______________________________________________
gnome-os-list mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/gnome-os-list
