[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [atomic-devel] xdg-open-gateway
- From: Neal Gompa <ngompa13 gmail com>
- To: mclasen redhat com
- Cc: atomic-devel projectatomic io
- Subject: Re: [atomic-devel] xdg-open-gateway
- Date: Wed, 20 Jun 2018 09:16:16 -0400
On Wed, Jun 20, 2018 at 9:09 AM Matthias Clasen <mclasen redhat com> wrote:
>
>
>
> On Wed, Jun 20, 2018 at 9:02 AM Neal Gompa <ngompa13 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!
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]