On Wed, Jun 20, 2018 at 9:09 AM Matthias Clasen <mcla...@redhat.com> wrote: > > > > On Wed, Jun 20, 2018 at 9:02 AM Neal Gompa <ngomp...@gmail.com> wrote: >> >> >> There are two binaries: one for the host (dbus-activated) and one for >> the sandbox (bind mounted in to overload /usr/bin/xdg-open). For >> sandbox setups that don't require all the overhead of flatpak (such as >> manual bubblewrap setups, sbox[1], firejail stuff, etc.), >> xdg-open-gateway works. >> >> The issue with the portal stuff is that it requires applications at >> some level to have the awareness to behave differently. That's >> fundamentally problematic if the goal is to be able to sandbox >> arbitrary applications. Usually, this is at the toolkit level, but it >> doesn't have to be, and ultimately, something has to do it. > > > I agree that apps need to be aware of being sandboxed. No way around that. > Pretending that it is not the case does not help. However, in this case, I > don't > see the 'portal issue' at all. But that is ok, we don't have to agree. > >
The thing is, you don't always get to be able to do that, and it is prudent to be able to have approaches to apply sandboxes to arbitrary application code. Sandboxing has always been orthogonal to application build and distribution, it's just easier in many cases to hit two birds with one stone. But there are definitely instances where you can't control the distribution mechanism but you can control how the application itself is run. -- 真実はいつも一つ！/ Always, there's only one truth!
