*scratch*https://www.scrivano.org
everything that doesn't fit in 280 charactersFri, 12 Oct 2018 09:14:21 +0000en-UShourly1https://wordpress.org/?v=4.9.8rootless podman from upstream on Centos 7https://www.scrivano.org/2018/10/12/rootless-podman-from-upstream-on-centos-7/
https://www.scrivano.org/2018/10/12/rootless-podman-from-upstream-on-centos-7/#respondFri, 12 Oct 2018 09:14:21 +0000https://www.scrivano.org/?p=297this is the recipe I use to build podman from upstream on Centos 7 and use rootless containers. We need an updated version of the shadow utils as newuidmap and newgidmap are not present on Centos 7. Using make install is not the correct way to install packages, and it will also overwrite existing The … Continue reading rootless podman from upstream on Centos 7

]]>this is the recipe I use to build podman from upstream on Centos 7 and use rootless containers. We need an updated version of the shadow utils as newuidmap and newgidmap are not present on Centos 7. Using make install is not the correct way to install packages, and it will also overwrite existing The shadow utils are installed using “make install” which is not the clean way to install packages and it also overwrite the existing binaries, but it is fine on a development system. Podman is already present on Centos 7 and in facts we install it so we don’t have to worry about conmon and other dependencies.

]]>https://www.scrivano.org/2018/10/12/rootless-podman-from-upstream-on-centos-7/feed/0network namespaces for unprivileged usershttps://www.scrivano.org/2018/08/05/network-namespaces-for-unprivileged-users/
https://www.scrivano.org/2018/08/05/network-namespaces-for-unprivileged-users/#respondSun, 05 Aug 2018 13:54:44 +0000https://www.scrivano.org/?p=279a couple of weekends ago I’ve played with libslirp and put together slirp-forwarder. SliRP emulates in userspace a TCP/IP stack. It can be used to circumvent the limitation of creating TAP/TUN devices in the host namespace for an unprivileged user. The program could run in the host namespace, receive messages from the network namespace where … Continue reading network namespaces for unprivileged users

]]>a couple of weekends ago I’ve played with libslirp and put together slirp-forwarder.

SliRP emulates in userspace a TCP/IP stack. It can be used to circumvent the limitation of creating TAP/TUN devices in the host namespace for an unprivileged user. The program could run in the host namespace, receive messages from the network namespace where a TAP device is configured, and forward them to the outside world using unprivileged operations such as opening another connection to the destination host. Privileged operations are still not possible outside of the emulated network, as the helper program doesn’t gain any additional privilege that running as an unprivileged user.

Once the PoC was ready, I discovered there was already another tool by Akihiro Suda (@AkihiroSuda), slirp4netns that was doing exactly the same thing, and it was already using the better slirp implementation in QEMU, that is used for configuring unprivileged virtual machines.

With some small changes to slirp4netns, it was possible to integrate slirp4netns into Podman for the configuration of an unprivileged network namespace. For example, we needed a way to terminate the slirp4netns program once the container exits, allow to configure the interface and notify Podman back once the configuration is done.

This is how it looks from the host, the arguments to slirp4netns in addition to some fd used for the synchronization, are the PID of a process in the network namespace to configure and the device name.

]]>https://www.scrivano.org/2018/08/05/network-namespaces-for-unprivileged-users/feed/0become-root in an user namespacehttps://www.scrivano.org/2018/07/19/become-root-in-an-user-namespace/
https://www.scrivano.org/2018/07/19/become-root-in-an-user-namespace/#respondThu, 19 Jul 2018 08:28:06 +0000https://www.scrivano.org/?p=268I’ve cleaned up some C files I was using locally for hacking with user namespaces and uploaded them to a new repository on github: https://github.com/giuseppe/become-root. Creating an user namespace can be easily done with unshare(1) and get the current user mapped to root with unshare -r COMMAND but it doesn’t support the mapping of multiple … Continue reading become-root in an user namespace

Creating an user namespace can be easily done with unshare(1) and get the current user mapped to root with unshare -r COMMAND but it doesn’t support the mapping of multiple uids/gids. For doing that it is necessary to use the suid newuidmap and newgidmap tools, that allocates multiple uids/gids to unprivileged users accordingly to the configuration files:

become-root doesn’t allow any customization, it statically maps the current user to the root in the user namespace and any additional uid/gid are mapped starting from 1.

One feature that might be nice to have is to allow the creation of other namespaces as part of the same unshare syscall, such as creating a mount or network namespace, but I’ve not added this feature as I am not using it, I rely on unshare(1) for more features. PR are welcome.

]]>https://www.scrivano.org/2018/07/19/become-root-in-an-user-namespace/feed/0fuse-overlayfs moved to github.com/containershttps://www.scrivano.org/2018/07/13/fuse-overlayfs-moved-to-github-com-containers/
https://www.scrivano.org/2018/07/13/fuse-overlayfs-moved-to-github-com-containers/#respondFri, 13 Jul 2018 22:00:59 +0000https://www.scrivano.org/?p=262The project I was working on in the last weeks was moved under the github.com/containers umbrella. With Linux 4.18 it will be possible to mount a FUSE file system in an user namespace. fuse-overlayfs is an implementation in user space of the overlay file system already present in the Linux kernel, but that can be … Continue reading fuse-overlayfs moved to github.com/containers

With Linux 4.18 it will be possible to mount a FUSE file system in an user namespace. fuse-overlayfs is an implementation in user space of the overlay file system already present in the Linux kernel, but that can be mounted only by the root user. Union file systems were around for a long time, allowing multiple layers to be stacked on top of each other where usually the last one is the only writeable.
Overlay is an union file system widely used for mounting OCI image. Each OCI image is made up of different layers, each layer can be used by different images. A list of layers, stacked on each other gives the final image that is used by a container. The last level, that is writeable, is specific for the container. This model enables different containers to use the same image that is accessible as read-only from the lower layers of the overlay file system.

The current implementation of the overlay file system is done directly in the kernel, at a very low level, allowing non privileged users to use it directly poses some security risks. In the longer term, once the security aspect is resolved, non privileged users will probably be able to mount directly an overlay file system.

For now, given the new feature in Linux 5.18, having an implementation of the overlay union in user space will enable rootless containers to use the same storage as containers running as root.

On Fedora Rawhide, where Linux 4.18 is available, it is already possible to take a taste of it with:

]]>https://www.scrivano.org/2018/07/13/fuse-overlayfs-moved-to-github-com-containers/feed/0Current status (and problems) of running Buildah as non roothttps://www.scrivano.org/2018/02/25/current-status-problems-running-buildah-non-root/
https://www.scrivano.org/2018/02/25/current-status-problems-running-buildah-non-root/#respondSun, 25 Feb 2018 13:59:14 +0000https://www.scrivano.org/?p=240Having Buildah running in an user namespace opens the possibility of building container images as a not root user. I’ve done some work to get Buildah running in an user container. There are still some open issues to get it fully working. The biggest open one is that overlayfs cannot be currently used as non … Continue reading Current status (and problems) of running Buildah as non root

]]>Having Buildah running in an user namespace opens the possibility of building container images as a not root user. I’ve done some work to get Buildah running in an user container.

There are still some open issues to get it fully working. The biggest open one is that overlayfs cannot be currently used as non root user. There is some work going on, but this will require changes in the kernel and the way extended attributes work for overlay. The alternative is far from ideal and it is to use the vfs storage driver, but it is a good starting point to get things moving and see how far we get. (Another possibility that doesn’t require changes in the kernel would be an OSTree storage for Buildah, but that is a different story).

Circumvented the first obstacle, the other big issue was to get a container, that is created for every buildah run command, the Buildah version of the RUN directive in a Dockerfile. That means run a container inside of a container.

The default runtime for atomic –user is bwrap-oci, a tool that converts a subset of the OCI configuration file to a command line for bubblewrap, the real engine for running the container. There is an open issue with bubblewrap, that as part of the container setup, move the container in a chroot. This will prevent further containers to be created as for the unshare(2) man page, you can get an EPERM if:

EPERM (since Linux 3.9)
CLONE_NEWUSER was specified in flags and the caller is in a chroot environment (i.e., the caller’s root directory does not match the root directory of the mount namespace in which it resides).

This problem is tracked here: https://github.com/projectatomic/bubblewrap/pull/172. Once that is merged, together with some other small changes in bwrap-oci I got the container running and bubblewrap could be used both as the runtime for running the Buildah container that for the runtime for managing the containers created by Buildah.

I wanted to give it a try with runc as well as the container runtime. There is a lot of development going on upstream for running containers as not root user, but it also failed to run in an user namespace when it tried to setup the cgroups.

To get a better understanding of what could the solution for having a full OCI runtime managing these containers, I wrote some patches for crun, partly because it is my pet project and also as it is still experimental, it is much easier to quickly throw a bunch of patches at it and not be worried to make someone sad. I’ve added some code to detect when the container is running in an user namespace and relax some error conditions to deal with the limitations in such environment. Even if the user id is 0 the runtime doesn’t still have full control of the system.

The container image that I’ve prepared is hosted on Docker hub at docker.io/gscrivano/buildah.

Given you use the latest version crun from git and of the atomic CLI tool (that supports –runtime) you can run the container as:

]]>https://www.scrivano.org/2018/02/25/current-status-problems-running-buildah-non-root/feed/0New COPR repository for crunhttps://www.scrivano.org/2017/11/15/new-copr-repository-crun/
https://www.scrivano.org/2017/11/15/new-copr-repository-crun/#respondWed, 15 Nov 2017 19:25:46 +0000https://www.scrivano.org/?p=229I made a new COPR repository for CRUN so that it can be easily tested on Fedora: https://copr.fedorainfracloud.org/coprs/gscrivano/crun/ To install crun on Fedora, it is enough to: # dnf install 'dnf-command(copr)' # dnf -y copr enable gscrivano/crun # dnf install -y crun a recent change in the atomic tool, which didn’t still get into a … Continue reading New COPR repository for crun

a recent change in the atomic tool, which didn’t still get into a release, allows to easily override the OCI runtime for system containers. Assuming you are using atomic from the upstream repository, you can use crun as:

]]>https://www.scrivano.org/2017/11/15/new-copr-repository-crun/feed/0C is a better fit for tools like an OCI runtimehttps://www.scrivano.org/2017/10/23/c-still-makes-sense-low-level-tools-oci-runtime/
https://www.scrivano.org/2017/10/23/c-still-makes-sense-low-level-tools-oci-runtime/#respondMon, 23 Oct 2017 21:21:19 +0000https://www.scrivano.org/?p=213I’ve spent some of the last weeks working on a replacement for runC, the most used/known OCI runtime for running containers. It might not be very well known, but it is a key component for running containers. Every Docker container ultimately runs through runC. Having containers running through some common specs allow some pieces to … Continue reading C is a better fit for tools like an OCI runtime

]]>I’ve spent some of the last weeks working on a replacement for runC, the most used/known OCI runtime for running containers. It might not be very well known, but it is a key component for running containers. Every Docker container ultimately runs through runC.

Having containers running through some common specs allow some pieces to be replaced without having any difference in behavior.

The OCI runtime specs describe how a container looks like once it is running, for instance it lists all the mount points, the capabilities left to the process, the process that must be executed, the namespaces to create and so on.

While the rest of the containers ecosystem is written in Go, from Docker to Kubernetes, I think that for such a low level tool C still makes more sense. runC itself uses C for its lower level tasks forking itself once the configuration done and setting up the environment in C before launching the container process.

I’ve tried running sequentially 100 times a container that runs only /bin/true and the results are quite good:

Most of the time for running a container seems to be in the creation of a network namespace. I had expected some costs in the Go->C process handling but I am surprised by the results when the network namespace is not used as crun is almost double as fast as runC.

]]>https://www.scrivano.org/2017/10/23/c-still-makes-sense-low-level-tools-oci-runtime/feed/0OpenShift on system containershttps://www.scrivano.org/2017/02/23/openshift-system-containers/
https://www.scrivano.org/2017/02/23/openshift-system-containers/#respondThu, 23 Feb 2017 18:26:43 +0000http://www.scrivano.org/?p=123It is still an ongoing work not ready for production, but the upstream version of OpenShift origin has already an experimental support for running OpenShift Origin using system containers. The “latest” Docker image for origin, node and openvswitch, the 3 components we need, are automatically pushed to docker.io, so we can use these for our … Continue reading OpenShift on system containers

]]>It is still an ongoing work not ready for production, but the upstream version of OpenShift origin has already an experimental support for running OpenShift Origin using system containers. The “latest” Docker image for origin, node and openvswitch, the 3 components we need, are automatically pushed to docker.io, so we can use these for our test. The rhel7/etcd system container image instead is pulled from the Red Hat registry.

The Vagrantfile will provision three virtual machines based on the `fedora/25-atomic-host` image. One machine will be used for the master node, the other two will be used as nodes. I am using static IPs for them so that it is easier to refer to them from the Ansible playbook and to require DNS configuration.

The machines can finally be provisioned with vagrant as:

# vagrant up --provider libvirt

At this point you should be able to login into the VMs as root using your ssh key:

for host in 10.0.0.{10,11,12};
do
ssh -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no root@$host "echo yes I could login on $host"
done
yes I could login on 10.0.0.10
yes I could login on 10.0.0.11
yes I could login on 10.0.0.12

Our VMs are ready. Let’ install OpenShift!

This is the inventory file used for openshift-ansible, store it in a file origin.inventory:

The new configuration required to run system containers is quite visible in the inventory file. `use_system_containers=True` is required to tell the installer to use system containers, `system_images_registry` specifies the registry from where the system containers must be pulled.

And we can finally run the installer, using python3, from the directory where we forked ansible-openshift:

$ oc login --insecure-skip-tls-verify=false 10.0.0.10:8443 -u user -p OriginUser
Login successful.
You don't have any projects. You can try to create a new project, by running
oc new-project
$ oc new-project test
Now using project "test" on server "https://10.0.0.10:8443".
You can add applications to this project with the 'new-app' command. For example, try:
oc new-app centos/ruby-22-centos7~https://github.com/openshift/ruby-ex.git
to build a new example application in Ruby.
$ oc new-app https://github.com/giuseppe/hello-openshift-plus.git
--> Found Docker image 1f8ec11 (6 days old) from Docker Hub for "fedora"
* An image stream will be created as "fedora:latest" that will track the source image
* A Docker build using source code from https://github.com/giuseppe/hello-openshift-plus.git will be created
* The resulting image will be pushed to image stream "hello-openshift-plus:latest"
* Every time "fedora:latest" changes a new build will be triggered
* This image will be deployed in deployment config "hello-openshift-plus"
* Ports 8080, 8888 will be load balanced by service "hello-openshift-plus"
* Other containers can access this service through the hostname "hello-openshift-plus"
* WARNING: Image "fedora" runs as the 'root' user which may not be permitted by your cluster administrator
--> Creating resources ...
imagestream "fedora" created
imagestream "hello-openshift-plus" created
buildconfig "hello-openshift-plus" created
deploymentconfig "hello-openshift-plus" created
service "hello-openshift-plus" created
--> Success
Build scheduled, use 'oc logs -f bc/hello-openshift-plus' to track its progress.
Run 'oc status' to view your app.

After some time, we can see our service running:

oc get service
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hello-openshift-plus 172.30.204.140 8080/TCP,8888/TCP 46m

Are we really running on system containers? Let’s check it out on master and one node:

(The atomic command upstream has a breaking change so with future versions of atomic we will need -f backend=ostree to filter system containers, as clearly ostree is not a runtime)

]]>https://www.scrivano.org/2017/02/23/openshift-system-containers/feed/0System containers presentation https://www.scrivano.org/2017/01/30/system-containers-presentation/
https://www.scrivano.org/2017/01/30/system-containers-presentation/#respondMon, 30 Jan 2017 18:41:37 +0000http://www.scrivano.org/?p=114Here the slides for the Atomic System Containers talk I gave at Devconf.cz 2017: http://scrivano.org/static/system-containers-demo/ If you are interested in the video, it is on YouTube: https://www.youtube.com/watch?v=yQZiRWWEPYo

]]>https://www.scrivano.org/2017/01/30/system-containers-presentation/feed/0Facebook detox? https://www.scrivano.org/2016/12/27/facebook-detox/
https://www.scrivano.org/2016/12/27/facebook-detox/#respondTue, 27 Dec 2016 20:52:47 +0000http://www.scrivano.org/?p=110I have been using Facebook for the last years to fill every dead time:waiting for the bus, ads on TV, compiling, etc. The quality of the information coming from Facebook is inferior to any other social network, at least to my experience (it can be I follow/know the wrong people), though the part of the … Continue reading Facebook detox?

]]>I have been using Facebook for the last years to fill every dead time:waiting for the bus, ads on TV, compiling, etc. The quality of the information coming from Facebook is inferior to any other social network, at least to my experience (it can be I follow/know the wrong people), though the part of the brain that controls procrastination seems addicted to this lower quality information and the chattering there. Also, I don’t want to simply delete my Facebook account and move on, most of the people I know are present only there, neither I want to be more “asocial”.

The Android market has always a solution. An app let you define rules on how long are you permitted to use each app. I am self limiting myself to ten minutes per day of Facebook. Second day and the rule is still in place without exceptions!