Using Easy Containers

Page originally written October 18, 2019
Updated: April 29, 2022

Running an application in a container, is a mechanism to achieve isolation from the rest of the system and higher security than if the application were run in the normal way.

There is another web-page which is a technical overview of EasyOS from the user-perspective, including an introduction to Easy Containers (EC):

https://easyos.org/tech/how-easy-works-part-2.html 

...please read the section that introduces Easy Containers, as it provides the basis to understand what follows.

This page is intended to provide addition usage notes. As described in the above link, containerized apps show on the desktop with a "padlock" symbol at top-left of each icon, for example:

Clicking on one of these will run the app in a container. In the case of "www", it will start the Firefox web browser, and it will be just like the normal Firefox (note, in Easy prior to 3.4, www runs SeaMonkey). From the user-perspective, you will notice some differences though:

1. A tiny bit slower to startup.
2. Open and Save files can only be within the container.
3. Extensions/add-ons/themes not shared with the system-Firefox.
4. There may be issues with Internet connection.
   

You are, in fact, running Firefox in it's own private operating system, running as "crippled root". Although a container is isolated from the main desktop, it is not perfect isolation. There has to be some interaction, for example to achieve Internet connection via the connection already established on the main desktop.

This required interaction also means potential security weaknesses, however, we try to make it very difficult to break out of a container. So yes, you are considerably more secure.

Regarding point-4, there are sometimes issues with network access from within a container, especially as we attempt to tighten up the security (isolation) settings. Generally, ethernet network connection is better than wi-fi in this regard.

Sharing files with the main desktop

That is point-2 in above list, but that is from the point of view of being inside the container. From the main desktop, you can see inside all of the containers, and do anything that you want in them, including read and write files.

Regardless whether running an app on the main desktop or inside a container, most apps will default to open|save|download to /files, or a sub-folder inside /files. For example, Firefox defaults to download files to /files/downloads.

On the main desktop, the files folder is actually in the working-partition, and is bind-mounted on /files. This is explained here:

https://bkhome.org/news/202112/all-downloads-now-to-files-folder.html

However, inside a container there is no access to drive partitions, everything is in RAM, and so is /files. This is for security reasons.

However, by a bit of magic, folder /files/shared on the main desktop is the same as /files/shared inside the container. So, if, for example you download a file while running the web browser inside a container, to make that file available to the main desktop, just save it to /files/shared.

And vice-versa. Though, as already stated, you can read and write anywhere in a container from the main desktop. For example, if the "www" container is running, then if you point the file-manager at /mnt/wkg/containers/www/container, you can access everything inside the container. This is further explained here:

https://bkhome.org/news/202204/some-handy-tricks-with-easy-containers.html

...yes, you are God as far as the containers are concerned!

Run SFSs of other distributions

There is something very nice about SFSget, the SFS downloader and installer, run by clicking the icon labeled "sfsget" on the desktop. That niceness is that you can run any SFSs, regardless of what Linux distribution it is created for.

An app is compiled to work on a particular distribution, and version of that distribution, and may not work on other distributions. This could be due to wrong versions of libraries, or missing dependencies. However, with Easy Containers, that is not a problem.

At the time of writing (April 2022), the latest version of EasyOS is 3.4.7, the "Dunfell" series. The packages for this series are compiled from source using a fork of OpenEmbedded.

Prior to Dunfell, was the "Buster" series. The Buster series, that started with 2.0, is built with binary packages from the Debian Buster 10 distribution. Buster is now retired.

There is also an older series of EasyOS, known as the "Pyro" series, version numbers 1.x and the latest is 1.2.3. Easy Pyro is built with packages compiled from source using a fork of OpenEmbedded. Pyro is now retired.

The point is, Dunfell, Buster and Pyro are different distributions, and the same principle will apply, that an app compiled for, say, Pyro, might not work in Buster or Dunfell. However, Easy Containers fixes that.

When this webpage was originally written, in 2019, Buster was the current release, so the discussion below, and snapshots, are for Buster...

If you are running Buster, and click on the "sfsget" icon, this is the window:

...you can see various SFS files, that can be downloaded, and you can choose to run them in a container or on the main desktop.

See the other path "easyos/oe/pyro". That has SFS files for Pyro. If you click that radiobutton:

...take "pingus" for example. That is a game, compiled to run on Easy Pyro. If you were to download and install it, it can only be run in a container, in a layered filesystem with easy_1.2.2_amd64.sfs on the bottom. So you are really running the complete Pyro distro, but just the one app in it.

However, if you select "easy_1.2.2_amd64.sfs", as shown in the above snapshot, and click the "Download" button. it will install as a complete Easy Pyro desktop. In other words, after installing, this is what you would see on the desktop:

...yes, you can run either Buster or Pyro as complete desktops in a container. If you click on "pyro", you get the familiar desktop of that series;

A detail note: If you had previously installed "Pingus", then easy_1.2.2_amd64.sfs would already have been downloaded, so the above SFSget window would show "Install" in the button, instead of "Download". You can then proceed to install Easy Pyro as a containerised desktop.

Flipping and killing containers

Click on "pyro" icon will launch the Easy Pyro containerized desktop. ALT-F6 will flip you back to the main desktop. On the main desktop, click either the "pyro" icon or the entry in the tray to flip back into the Pyro container.

But how to kill a container? If running a single app in a container, such as Pingus, closing the app will also kill the container.

There is another way to kill a container, and this method is required if you want to kill the Pyro container. On the main desktop, right-click on the tray entry, and choose "Kill":

Compile source code in a container

Compiling source packages in a container is convenient as it does not clutter up the main desktop. Sometimes also, a compiled and installed package may make the main desktop misbehave.

Barry recently wanted to compile the latest Xorg and drivers for Easy Pyro. He used the "console" container to do this (see icon at centre-top of screen). What is wanted is the isolation, but keep full power of the administrator -- for this reason, Barry changed the security settings of the "console" container to "security level 1", least secure. This is achieved by running Easy Container Management (in the Filesystem menu):

...the procedure is to choose "console" in the "Manage" frame, then click "A container with absolute minimum security" in the "Security level" frame, then click "Update & exit" button.

You will need the "devx" SFS file, which has everything needed to compile: click the "sfsget" icon on the desktop to download and install to the "console" container.

When the container is started, by clicking on the "console" icon centre-top of screen, a terminal will run within the container, with security level 1.

Note, this requires Easy Pyro 1.2.7 or Buster 2.1.7 versions (or later), as earlier versions have bugs in the 'easy-containers' and 'sfsget' scripts.

A practical usage detail: the terminal will only be seeing folders within the container, but from outside, the path to the container is /mnt/wkg/containers/console/container, and the important detail is that you have full access from the main desktop. Thus you can download source packages into the container.

The normal compile steps are like this:

# ./configure --help
# ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --build=x86_64-pc-linux-gnu etc  
# make
# new2dir make install
# dir2pet name-of-directory  

The packages will be installed in the container, and the PET packages can be copied out.

more coming... 

Tags: user