xdg-open from within an xdg-app?

[Stephan Bergmann]

On 02/23/2016 11:58 AM, Alexander Larsson wrote:
> On tis, 2016-02-23 at 09:43 +0100, Stephan Bergmann wrote:
>> [Hi all; I thought I had subscribed to this list long ago, but
>> apparently hadn't, and only seen the few mails that got crossposted
>> to
>> gnome-os-list; so if the below has already been discussed, please
>> just
>> point me to the archives.]
>>
>> I'm trying to package LibreOffice (LO) as an xdg-app, and one thing
>> LO
>> wants to occasionally do is call other apps to handle some URLs
>> (like
>> calling a browser when clicking on a hyperlink in a Writer doc), in
>> the
>> xdg-open style.  However, doing so from an xdg-app sandbox (even a
>> fully
>> privileged one) of course does not work.
>>
>> So what I thought about is a trivial DBus service running outside
>> the
>> sandbox that just forwards any arguments to xdg-open.  Is that
>> something
>> that we would want to add?
>
> This is essentially what portals are. Plus some host-side UI to
> guarantee that this is safe.
>
>> (In its simplest form, that service would arguably have security
>> implications for unprivileged apps, but it could be opt-in on
>> --socket=session-bus.  My first aim at least for a sandboxed LO is
>> to
>> give it full privileges, anyway.)
>
> Opening a url, and opening a local file with another app, is one of the
> first portals I plan to work on. I was hoping to start working on the
> portals by now, but a lot of other stuff is getting in the way.
> However, I hope to work on this soon.

This xdg-open issue is somewhat special, though, in that even if an app 
isn't really sandboxed and is granted arbitrary capabilities, it still 
cannot reach out to the host's xdg-open.  That IMO makes a solution for 
this portal more urgent than for other portals (where the typical 
workaround is to give the app more capabilities, like full filesystem 
access, until a portal solution is available).

What would be a convenient solution for apps (at least, it would be for 
LibreOffice), is if a runtime could provide an xdg-open executable that 
passes its argument through the portal.  (That way, applications could 
continue to transparently call out to xdg-open and wouldn't need special 
code when packaged for xdg-app.)  (Plus maybe even a capability flag to 
allow apps "unsandboxed" access through that portal, so that initiating 
an xdg-open request doesn't need to trigger any "Do you want to allow 
this app to open that URL?" user interaction from the portal, if the 
user trusts the app.  That could also be a workaround to offer xdg-open 
functionality to apps sooner, before a fully-fledged portal is available.)