Atomic workstation

[Daniel J Walsh]

On 12/03/2014 05:05 PM, drago01 wrote:
> On Wed, Dec 3, 2014 at 11:00 PM, Josh Boyer <jwboyer at fedoraproject.org> wrote:
>> On Wed, Dec 3, 2014 at 4:40 PM, Colin Walters <walters at verbum.org> wrote:
>>> On Wed, Dec 3, 2014, at 03:47 PM, Josh Boyer wrote:
>>>> Out of curiosity, couldn't you have an atomic/ostree "base" layer that
>>>> is immutable (perhaps shared between Base, Server, Cloud,
>>>> Workstation), and then use Docker containers on top of that as the
>>>> "live" system?
>>> Good point, I didn't bring up the Docker part of Project Atomic.  I think
>>> it makes a significant amount of sense for Workstation to be investigating
>>> using Docker for developer tooling, and that's already happening.  Actually
>>> containers for server side code help bring together the Server/Workstation
>>> story far more than we ever had before.
>>>
>>> Previously in the package model, you can of course "yum install httpd $language"
>>> on your workstation and start making a web app and testing it locally,
>>> and many people do this today.  But taking that same app
>>> and ship it to a server had a different model.  With containers, it becomes
>>> a lot easier.
>>>
>>> It's also a huge benefit for web apps on the desktop to have isolated ports -
>>> Docker makes it easy to have two web apps that both think they're listening
>>> on port 80, and on the desktop you just look at "docker ps" to find where
>>> they are.
>>>
>>> That said, this story breaks down a bit when one introduces clustering,
>>> and that starts to lead back to local Vagrant usage or the like.
>>>
>>>> That would still fit with the "atomic is for Docker"
>>>> approach you have today, while also giving some flexibility at the
>>>> application layer.   One could imagine Software installations become
>>>> "create a new Docker container with this app inside of it", which then
>>>> leads to it be automatically sandboxed, etc.
>>> No.  Docker (alone) is not a desktop sandbox tool.  As soon as any process
>>> connects to your X server it has total control and could be a keylogger,
>>> write data into your terminals, etc.
>> With X, yes.  It's not _worse_ than just running it all from the same
>> OS install though.
>> I thought this was less of a concern with Wayland, but I will admit I
>> could be wrong.
> No you are not wrong clients are isolated from each other on wayland.
> See https://wiki.gnome.org/Initiatives/Wayland the "why switch to
> wayland" part.
My understanding is for true container isolation you need lots of
changes to the desktop,

You need to have Wayland to eliminate the X Problem.
You need to have a new "File Manager" App that the Apps could some how
launch.  Since you still want firefox download to actually download to
the desktop/homedir in a location the user selects.  This writing to the
desktop/homedir can not be controlled by the firefox container, but has
to be handled by a new mechanism see kdbus.  Where the "File Manager"
hands firefox a "File system object" that it can write but not create. 

Then you have to worry about system defaults.  If the user wants to
change the screen background colors you need to communicate these into
the container application.

Helper apps like Colin described have to be handled.  Firefox launches
evince, openoffice, random desktop plugins like flashplugin, and
bjplugin.  If firefox and thunderbird both use the plugin, will the user
need to download it multiple times?  If I launch ooffice to view a .doc
file in firefox, do I want this ooffice container to be the same ooffice
container that I have currently containing the Coke Secret Recepe, or
should it be in a separate ooffice container so my secrets can not be
hijacked?

Lots of potential problems if you use full container isolation like
docker at the desktop.  Using something that does more sharing of /usr
into the container might make this easier.

As I found when I wrote the SELinux Sandbox.  The Linux Desktop is a
"cess pool" of communication and attempting to sandbox apps will have
unexpected consequences.