xdg-open from within an xdg-app?

[Alexander Larsson]

On tis, 2016-04-19 at 11:44 +0200, Stephan Bergmann wrote:
> 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).

Yeah, but it is also very security sensitive, since it is a "run this
command outside the sandbox" operation. So, we have to be very careful
with how it works.

> 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.)

I hope to have glib/gio use the portal automatically, which should make
xdg-open use that. As mentioned above, this require pretty careful
consideration though. I don't want to do a quick hack to make it work
for now.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a witless Republican waffle chef looking for 'the Big One.' She's a 
supernatural gold-digging angel from Mars. They fight crime!