If the chosen application is sandboxed itself, the open uri portal need to make sure that a local file is available, by exporting it to the document portal.

As mentioned on IRC today, I found that the OpenFile method won't handle FDs pointing to directories even in the case where such directories are reachable both inside and outside the sandbox, which is kind of a problem for situation like one we have on Endless, where the Dropbox app (which has filesystem=home permissions granted) tries to open the file manager in the "Dropbox directory".

I've discussed this with @alexlarsson and he seems to agree on that we can add an additional check in https://github.com/flatpak/xdg-desktop-portal/blob/master/src/xdp-utils.c#L340, so that fail when the FD passed points to something that is neither a regular file nor a directory (instead of checking just for regular files).

This, of course, won't be useful in cases where such directory is not reachable inside the sandbox, since those kind of paths would need to be handled via the documents portal, and FUSE does not support directories, but it can be useful nonetheless in cases like the mentioned here.

I'll be linking to a PR soon later today.

Now see the full IRC log, for reference:

<msanchez> alexlarsson: hi, quick question about the OpenFile method if you don't mind me asking...
<alexlarsson> sure
<msanchez> only let me find a link first
<msanchez> https://github.com/flatpak/xdg-desktop-portal/blob/master/src/xdp-utils.c#L340
<msanchez> can you think of any reason why we could not extend that to (mode != S_IFREG && mode != S_IFDIR)? 
<msanchez> the reason I ask is because it would be nice to keep being able to open not just regular files but also directories (assuming you have something to handle that such as Nautilus, of course)
<alexlarsson> Well, at a minimum the fuse filesystem for documents don't handle directories
<alexlarsson> But also, documents are made for "document level" files
<msanchez> I'm not 100% sure that's a problem here. I added that extra check in there to see if it would work and that did the trick for me
<msanchez> when passing the fd for /home/mario (in a sandbox with read permission to my home) I could see the mode matching S_IFDIR
<alexlarsson> That is not the issue though
<msanchez> and just doing that change was the difference between my Dropbox flatpak being able to open the Dropbox directory or not 
<msanchez> hmm... I guess I'm missing things then
<alexlarsson> I mean, you could register one
<alexlarsson> but, could you read the directory in //run/user/1000/doc ?
<alexlarsson> I'd be surprised if it worked at all
<msanchez> ah, right, I see what you mean
<alexlarsson> and its definately not designed to be safe to do that
<msanchez> in this case I suppose it works because I have filesystem=home permissions and the /home/mario dir is reachable both inside and outside the sandbox
<msanchez> still, I'd like to understand this better, since being able to open directories via the OpenFile method is kind of important to us
<alexlarsson> Wait a minute
<alexlarsson> does the OpenFile portal even create document portal objects
<alexlarsson> I guess it does if the destination app doesn't have access
<msanchez> no, it doesn't
<alexlarsson> But, i guess for other cases it would make sense for it to work.
<msanchez> https://github.com/flatpak/xdg-desktop-portal/commit/fa008ea5ece0785ac30165c4d416cf255b02252f
<alexlarsson> msanchez: well, flatpak itself does when you spawn a desktop file handler for it
<alexlarsson> But, i guess if the handler is not sandboxed
<alexlarsson> then it makes sense to allow this
<msanchez> hmm.. .I checked this with gdb and I saw clearly that, after me adding the additional check for S_IFDIR there, the path passed to Nautilus was the one I'd expect too: `file:///home/mario`
<alexlarsson> So, yeah, i think allowing dirs make sense here
<msanchez> but again, I understand that's because the path was reachable inside the sandbox in the first place
<msanchez> cool, thanks
<alexlarsson> well, thats sort of the point of using fds
<alexlarsson> that you can pass and fd is proof that your sandbox had access to it
<msanchez> yes, and I like it
<alexlarsson> the only problem is if the target thing of the openfile doesn't have access
<msanchez> well, that's not a problem in the case of the dropbox app, at least for now 
<alexlarsson> For files this is handled by flatpak rewriting the urls to documents as needed
<alexlarsson> which *doesnt* work for dirs
<msanchez> yes, the FUSE system
<alexlarsson> But, thats such an uncommon case, so lets just have that fail

It would be nice if apps could display basic OS information like name and version in their about dialog.

The kind of information that is normally found in /etc/os-release

Several of the portal frontends now have the same code to maintain a impl-handle->handle mapping. Would be nice if we could centralize that in one place.

GNOME shell already has the right dialog, and we use the permission store for it. But I think we should have a portal api in line with all the other portals for it. Can of course reuse all the existing infrastructure.

I think it could be a good idea to release a new version of xdg-desktop-portal and xdg-desktop-portal-gtk. The last version was released in June and there were many translation updates and other fixes since then.

These file chooser extensions are somewhat commonly used.

gedit, gimp, evolution... see https://bugzilla.gnome.org/show_bug.cgi?id=768014

i just realized that ComposeEmail has the same file access issue as the original OpenURI call had. We need to replace it with a different api that takes fds for the files to attach :-(

The screencast interface will be needed to fix things like screen sharing in bluejeans, webrtc, etc.

For screenshots, one suggested user experience is to first take the screenshot, then present a dialog with the result and ask "ok to share this with app foo ? "

For screencasts, pinos probably should be involved.

Notification portal expects that each application implements org.freedesktop.Application interface and actions triggered from a notification will call this interface. In KDE not all applications handle response from notifications that way as we can simply just watch actionActivated(int action) signal from created notification (using KNotification framework). The way KDE notifications work we will need a signal we can send back to an application running in sandbox.

Currently if you try to trash a file on the host using gio it will fail: gio: file:///foo: Unable to trash file /foo across filesystem boundaries. Perhaps this makes sense to expose as a portal?

When using the OpenFile method to deal with paths for which we have determined that we can skip showing the app chooser, the portal frontend will crash because uri will not be set when the following line is reached:

https://github.com/flatpak/xdg-desktop-portal/blob/8676f78/src/open-uri.c#L525

This is fairly uncommon as that situation of skipping the chooser will only happen in practice when opening directories (as for http/https the OpenURI method would be used, and because it's common to have only one file manager around), which has not been a problem since directories were not being handled... until now :-)

But I just filed issue #128 precisely to support directories too, making this a fairly more common problem.

See:
https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/

Applications using GTK+ should be able to use gtk_application_inhibit() as they did before, and GTK+ would poke a portal directly, instead of gnome-session (or org.freedesktop.ScreenSaver).

Note that the fd.o Inhibit API is less featureful than the gnome-session and GTK+ ones.

Add support for: https://developer.gnome.org/notification-spec/#hints

That way we should be able to pass custom properties through the notification portal. E.g. in KDE we use many custom properties that are just passed in "hints" as a simple variant map. It shouldn't be hard to support that, this might just be one more specified option in "notification" parameter in AddNotification method.

E.g. hints a{sv} - array of extra properties, the backend implementation is not required to support any of them

Initially, this can just be a simple 'print this pdf file' api.

Hi!

GIMP has this nifty new feature for opening RAW images, which is we use third-party advanced RAW software for the job. The idea is: why bother reimplementing a shitty 3-slider RAW developer as a plugin which will mostly be a toy when there are really good complete ones, and several being Free Software, like darktable or rawtherapee.
So now when someone tries to open a RAW in GIMP, we detect installed darktable and rawtherapee and redirect the call to the user's favorite RAW software (if both are installed, one can choose one's favorite in GIMP's preferences). When the editing stops on this third-party software, it automatically sends back the result to GIMP for further editing.

Unfortunately this feature stopped working with flatpak. Flatpaked GIMP don't see DT/RT installed by the system packaging, nor installed as flatpak.

Let's say we don't mind not detecting non-flatpak DT/RT. After all, flatpak is a sandbox and one of the goal is to shield the system. But couldn't there be an API to detect other flatpaks and being able to run them? I see there is a darktable flatpak for instance. It would be awesome if we could detect it within GIMP flatpak and run org.darktable.Darktable.

#115 is trying to paper over an inherent race in the current pattern we use for portal apis. The race exists because applications need to wait for the response to the method call before they can subscribe to the Response signal on the request object. The signal might have already been sent at that time. This race normally does not matter much, since the backends are expected to involve user interaction and dialogs, which normally takes a long time. But some portals (such as the email portal) just fork-and-forget the UI part and return right away, which makes it possible to hit the race. gnome-recipes is hitting it fairly frequently.

Here is a proposal for fixing it: Switch to a an object path for the request object that is unique, but can be known in advance. This lets the client-side subscribe to the Response signal before making the call.

To ensure uniqueness, the path should include both the senders unique name and a random token that is provided by the caller, in the options property bag.

Say: /org/freedesktop/portal/desktop/request/SENDER/TOKEN

I intend to have my application send an email. As of now, we have xdg-email which is supposed to be handling that. Within a flatpak app, we cannot call that on the host, though.

Currently, xdg-email claims to support the following arguments:

xdg-email [--utf8] [--cc address] [--bcc address] [--subject text] [--body text
] [--attach file] [ mailto-uri | address(es) ]

So I guess a compatible DBus API would support these (i.e. to, cc, bcc, subject, body, attachment), too.

FWIW: xdg-open "mailto:[email protected]?subject=foosubject&body=foobody&attach=/tmp/file" seems to work with Evolution, but I doubt that Thunderbird gets it right.

It is fairly common for a web browser or email client to want some way to set themselves as the default application for the user. It is also pretty clear that a sandboxed application shouldn't be able to unilaterally change the user's default application settings.

Would it make sense to add a portal interface for this? Perhaps something like this:

• IsDefault(mime_type, desktop_id) -> bool
  Returns true if the given desktop ID is the default for the given mime type. The portal may return false if the sandboxed app does not control the given desktop ID.

• SetDefault(mime_type, desktop_id)
  After confirming with the change with the user, set the given desktop ID as default handler for the given mime type. The portal will refuse to make the change if the sandboxed app does not control the given desktop ID. The portal may remember if the user's decision if they reject the change (to handle badly behaved apps that repeatedly try to change the settings).

It might need a bit more nuance though: a browser will probably want to set a number of x-scheme-hanlder/* defaults (http, https, etc), but the user should only be prompted once.

I just added an AccessDialog interface, and xdg-desktop-portal-gtk provides a gtk-based implementation. We can make it talk to gnome-shell (once it provides a similar interface) to use system-modals instead. Or we could just make gnome-shell provide this portal backend itself; but then we need priorities to make the gtk implementation the fallback that only gets used if gnome-shell is not around.

Access to speakers and microphones.

Hi,
I think portals should provide access to folders (and files too, probably) even after the application was closed and opened again.

A typical use case for this is a music player that maintains my music collection. I store my music on my portable drive - now assume this is always mounted on /mnt/music. In the app, I specify I want to listen to music from ~/Music but also from /mnt/music. The next time I start this app, it doesn't have the access to that folder and have to add it to the collection again. Meanwhile, I'd expect it to be able to manage it right away.

This would probably have to be a completely new call in the API and it's most likely not mappable to the current APIs so it's likely only flatpak-aware apps would take advantage of this feature.
A similar feature is implemented in the Windows UWP platform [1].

[1] https://docs.microsoft.com/en-us/uwp/api/Windows.Storage.AccessCache.StorageApplicationPermissions

As agreed during the GTK+ hackfest, we are implementing a new policy
for the OpenURI portal to try to improve the user's experience.

As per this new policy, the chooser dialog will NOT be shown when either:

• A default application is set in the system to handle the content type.
• Only one possible selection would be available to show on the dialog.

This would be an intermediate step while we don't have a better way to
handle default applications for specific schemes and/or content types.

Tagging @matthiasclasen @cosimoc @alexlarsson

Note: Copied over from flatpak/xdg-desktop-portal-gtk#55 as it is not specific to GTK

Currently when using the FileChooser portal from a sandboxed application the applications gets a path in the fuse file system. This is great for accessing the app, but there are a couple of use cases where I would like to know the absolute path of the file as the user selected it:

1. I want to inform the user where the file was saved
2. I want to allow the user to open the file location ("show in file manager"), e.g. by calling to the org.freedesktop.FileManager1 DBus interface
3. I want to save the last used location for later use. E.g. the user saved a file to $HOME/Videos/Last Vacation, the next time the user saves I want to open the file chooser at the same location.

The first 2 use cases partially work with the current implementation, but the location used and shown to the user (e.g. /run/user/1000/doc/d7c87a14) is not what is expected and looks confusing.

The third use case is currently impossible for what I can tell.

Would it be feasible to also report the absolute path as set by the user back to the calling sandboxed application (in addition to the fuse path, which is the actual usable path for the application)? Does this have security implications I am not aware of?

See:
https://blogs.gnome.org/uraeus/2015/06/30/introducing-pulse-video/

The variable substitution for the location for the flatpak D-Bus interfaces files does not fail if the pkg-config file is not present (but the variable ends up being empty).

Would it be possible to update the pofiles of xdg-desktop-portal and xdg-desktop-portal-gtk before releasing a new version? It would make translating a lot easier.

If an app wants to open a file in its own data, it will be a path in /app, this will not be mapped on the host, nor in the target app. This is common for instance if the app wants to spawn a reader for some docs (say a html or pdf) that is included with the app.

I think we need to identify this case and map /app to the actual location of the file is installed on the host system.

At the moment the OpenURI portal expects a, well, valid URI to be passed to work, otherwise it won't be able to parse the scheme and content type needed to open the resource outside the sandbox, which is a shame since sometimes that prevents the portal from doing useful things that are left ignored.

For instance, if you have a sandboxed application that tries to open a directory by specifying its path (e.g. /home/user/mydir, instead of file:///home/user/mydir) it would be nice if the OpenURI portal would handle that seamlessly and offered the user the option to use some application outside the sandbox to handle it (e.g. Nautilus).

This has been something we found out today while making a flatpak of dropbox using the --extra-data finish argument: despite of including Matt Watson's xdg-open shim for flatpak inside the sandbox, Dropbox client's "Open Folder" button (shown right after setting up the account) would refuse to work, which I found was caused because Dropbox was trying to do xdg-open /home/user/Dropbox, that did nothing for the reason mentioned above.

When xdg-desktop-portal is launched automatically by systemd, it doesn't use env variables so when you rely on XDG_CURRENT_DESKTOP you are not able to tell which backend to use. Launching xdg-desktop-portal manually it uses correct backend (KDE in my case), but when it is started automatically it uses fallback which is GTK frontend in my case.

To make sure the requesting app has access to the file, we should require an open fd. Alternatively, we could require that the app register the file with the document portal itself.

Not clear what do to about kernel keyring, need to talk to domain experts. We believe that libsecret should use the kernel keyring underneath.

Using org.gnome.Platform 3.22:

(sandbox) $ gtk-launch --version
3.22.0

Out of the flatpak sandbox, running this opens the picture viewer, but in the sandbox nothing happens: no error, no picture viewer.

$ identify file:///tmp/x.png
file:///tmp/x.png=>/tmp/x.png PNG 129x100 2560x1600+436+519 8-bit sRGB 6.08KB 0.000u 0:00.000

$ python3 -c "from gi.repository import Gio; Gio.AppInfo.launch_default_for_uri('file:///tmp/x.png', None)"

Is this the proper way to do it?

The GTK+ print dialog has this feature, and it is in use e.g. in gedit.
We can do something in the same style as the combobox support in the file chooser portal.

The idea for the sharing portal is that applications can describe support for this in their desktop file:

Implements: org.freedesktop.Share
...

[org.freedesktop.Share]
Types: images, text,... (mimetypes)

Currently, if you need access to gvfs functionality inside the sandbox, the only option is to allow access to gvfs-daemon, which makes all network mounts available.

There should maybe be a portal in the middle, for more granular access to gvfs functionality.

This should be easy to check now that we use the peer /.flatpak-info file to identify the peer app. This file contains the network access info.

With file uris, we risk unintentionally bypassing the sandbox restrictions on filesystem visibility, since the file is opened on the portal side, outside the sandbox. Alex and I discussed this in flatpak/flatpak#766 and agreed to do two things:

1. Drop handling of file: uris from the OpenURI method

2. Add an OpenFile method that takes an open fd instead of a uri

Even though I know the idea behind desktop portals is that the user will get some kind of visual feedback whenever the app leaves the sandbox (e.g. a dialog), for the particular case of the OpenURI portal it might be interesting to skip that step if there's only one candidate application available.

For instance, in the particular case of Endless's users this might very well be the case when opening http[s]:// URI schemes, since normally only one browser will be available and we don't want to expose that "detail" at all, so that they get a smooth experience (in a controlled environment).

So perhaps this is something that could be interesting for upstream too?

In request_init_invocation(), the following code is used to allocate a random unique request ID:

r = g_random_int ();
do
  {
    g_free (id);
    id = g_strdup_printf ("/org/freedesktop/portal/desktop/request/%u", r);
  }
while (g_hash_table_lookup (requests, id) != NULL);

Since the random number is only chosen once, if the ID conflicts in one iteration of the loop, it will always conflict.

Presumably a new random number should be chosen for each iteration of the loop.

If you drag a file into a sandboxed application the path will be on the host where you won't have access.

The name "xdg" implies this is a cross-* standard of some sort.

Is it?

• Is this supposed to end up in every distro (occasionally people a a bit quick to claim such when in fact the proposal has not really been discussed)?
• Is this supposed to end up in every desktop (e.g., KDE, XFCE, etc.) or is it a GNOME-only thing?
• Is this supposed to work with different packaging/bundling formats (e.g., Snap Packages and AppImage) as well, or is this purely a Flatpak-only thing?
• Is this supposed to work with different sandbox/confinement technologies (e.g., Firejail) or is it a Bubblewrap-only thing?

I am a bit confused because on the one hand, "xdg" suggests it has a very wide scope, but then there are files in the source code that suggest it is specific to Flatpak. Please clarify.

cdrom, dvd, joystick, etc. Need to treat them case-by-case.

Totem case: need full dvd access. Problem is that we can only set up device access at startup time, since we want to drop privileges. VLC also wants full optical device access, which is considered to be a showstopper for publishing VLC as a Flatpak.

joystick: one idea would be to have the compositor forward events in a somewhat transparent way. This has the advantage that we can subject these events to focus. But there's an open question if we need any custom ioctls. Need to talk to domain experts: sdl and libinput maintainers.

Richard wants to have usb access to update firmware. We tentatively agreed to just have a way to bind mount /dev in the metadata, for cases like this. Full device access is not quite as scary as it sounds since permissions still limit what is accessible.

Unfortunately, udev is not stable, so we can't just use libudev in the runtime. There was some idea that we might have a mini-udev wrapper for the host udev.

Nowadays, when users wants to interact with Nuvola Player in command line, they have to type long commands such as flatpak run --command=nuvolactl eu.tiliado.Nuvola track-info instead of plain nuvolactl track-info. If would be useful if there was a Flatpak portal that would let Nuvola to create the nuvolactl alias upon user's request.

Some of the portals, like the ones spawning dialogues, or launching URLs in remote handlers (Web, mail, etc.) should probably not do anything if the requester application is not focused, which would mean that the application programmatically generated this action, rather than the user.

Similarly joysticks, geolocation, are things that you might want to disallow once the application loses focus.

(for geolocation, it's a bit more complicated, some applications should be able to only access geolocation information when focused, for others, all the time, eg. an app to do social media checkins for the former, a navigation application for the latter)

We could have a very simplified vcard-based API that works as a frontend for eds/akonadi, with a way to get the current contacts and an update signal.

What is the pid used for in org.freedesktop.portal.Device.AccessDevice?
Can't we use the pid we get from the request, like the one we use for generic access control?

The problem with passing a pid is both that you can't trust it, anyone can pass in anyones pid, and secondly the pid namespace makes pids different in the sandbox and on the host.

The designers favor an approach where we show the annoying dialog a few times, and if the user makes the same choice a few times, we just go ahead and do it automatically from there on. I think we already do something like that for geolocation.

For open uri, that would imply that we a table of

requesting app + content-type -> chosen app + count

In addition, we need a way to let users set a threshold value for the count, including a way to say "always ask".

As mentioned in #30 (comment), it would be good to have a way to configure this threshold (and probably other portal-specific options that we might need) so that it can be adapted to different needs.

I initially thought of a key file under /etc, but perhaps GSettings is just fine, and cleaner/easier.