On Mon, Jul 17, 2017 at 2:48 PM, Michael Stahl
> On 17.07.2017 19:26, Richard W.M. Jones wrote:
>> On Mon, Jul 17, 2017 at 12:03:13PM +0200, Michael Stahl wrote:
>>> On 16.07.2017 12:54, Richard W.M. Jones wrote:
>>>> On Fri, Jul 14, 2017 at 04:59:37PM +0000, Debarshi Ray wrote:
>>>>> On Fri, Jul 14, 2017 at 09:44:18AM +0100, Richard W.M. Jones wrote:
>>>>>> If RPMs of the graphical application work fine now, what on earth
>>>>>> the point of forcing packagers to make Flatpaks? Sandboxing
>>>>>> of them - as already explained, sandboxing is orthogonal to
>>>>> Huh? How would you get sandboxing without Flatpaks? Unless you are
>>>>> proposing a different sandboxing technology.
>>>> Things like libvirt-sandbox have been around for a really long time
>>>> and don't require special packaging (in fact they work with any
>>>> arbitrary command).
>>> reading between the lines of the fine documentation, there is no mention
>>> of X11 or GUI applications, so i guess "arbitrary" is a bit of an
>> It seems like it's not mentioned in the docs, but it does work as in
>> this example of running evince to view a suspect PDF file:
> Note that the above example shares /tmp with the sandbox in order to
> give it access to the X11 socket. A better isolation can probably be
> achieved using xpra or xvnc but I haven't looked into this yet.
> so it doesn't actually sandbox very much, with access to the X11 socket
> the app can keylog and inject shell commands into terminal windows as
> much as it likes.
>> BTW libvirt sandbox allows either full-virt or container sandboxing.
> i'd hope if you don't use containers but full-virt it's going to use
> something more secure, like SPICE or something to display the GUI?
> but i'd call virtualization a bit of a heavy-weight approach.
> ... there's more prior art, the SELinux "sandbox -X", which at least
> starts a nested Xephyr for your convenience.
> these have in common that they're generally not very user friendly: you
> have to set up which files the program will have access to when you
> start it; also copy/paste probably doesn't work between the nested X
> server, which may or may not be a feature.
> FlatPak portals have the potential to be more user friendly since you
> can use the application's normal file picker to open files and the
> application only gets access to the file the user chooses.
Portals themselves are orthogonal to the Flatpak distribution
mechanism. They can be used with regular applications too.
I read this like containers are something new and interesting. Upstream
docker project started this effort a few years ago and the world has
latched onto it. Fedora needs to adjust and become great at
containers. Some of the interesting work we have been doing with atomic
host, and atomic workstation is great. We don't have to continue to do
things the way we have for 20 years. I believe Fedora needs to be at
the forefront of figuring out these container issues. Flatpacks
integration into the desktop gives us the potential of a great leap
forwards in security. Imagine if Fedora finally fixes the biggest
security issue of the desktop by running browsers in containers, in a
truly secure manner with it fully integrated, not hacked up like it is
in the SELinux Sandbox or by running docker images like Jess Frazelle was.
The stuff that flatpack is doing has been very good.
Colin Walters work on ostree and rpm-ostree is looking into how we can
do offline updates already and yet this discussion is ignoring it. This
stuff is great and it is currently controlled by Fedora we should be
taking advantage of it. I run the atomic workstation now and am running
flatpack, as well as development environments in containers. I feel
some pain, but we are learning how to deal with it.
We need to learn to live with combinations of rpm packages, ostree
distributions and containers running on Fedora.