A minmal A20 image

I started a new project with an minimal a20 image with non „mainstream“ components … see https://github.com/tjohann/a20_minimum_buildroot_dev … for example use musl, OpenRC, toybox …

Lets see if its works 🙂 …

Learn to use namespaces (part 2)

(PID) Namespace basic topics

With namespaces you can have multiple nested process trees (instead of one like in the „old“ days) … Every tree is isolated from the others … so it’s not possible to kill an process of the other namespace … even if the process id’s is the same within the different namespaces …
A process can have the same or a different pid within the namespaces -> namespaces are hierarchical … once a new namespace is created, all the tasks in the parent namespace will see the process in this new namespace, but processes from the new namespace will not see the ones from the parent

So every process needs more than one pid -> one for each namespace … The child process will have pid 1 and all orphaned process will re-parent to it … when this process dies, the namespace will be terminated! … so the child must be something like the „master“ … for example, a concurrent network server which spawns processes for the work should be the „master“ …

After creating a new namespace you should change the root dir and mount a new /proc instance. Otherwise procs like ps wont work … for example a user process creates a proc_myns dir, spawn a new namespace and mount /proc to that dir …

Learn to use namespaces (part 1)

After a time of „I have to learn more about containers“, I started to learn about  namespaces and in the next step the usage of cgroups to control such namespaces. In this series of articles I summarize in a short form all (for me) relevant parts. So lets start.

Why?
Through namespaces it’s possible do isolate one daemon/service from another one. Lets asume you got an breakin via an daemon/service. With that isolation it’s not possible to infect other daemon/service -> a root user inside the namespace does not have root privileges outside it!

A process within a namespace is running on the machine … instead a process running in kvm/qemu is running in an virtual machine …

Usecases:
– build a common software system based on different sources (and different trustlevel)
– continues integration -> every build runs in his own environment
– run multiple versions of the same program/daemon/service
– build packages within a container -> see void linux xbps

Namespaces -> kernel config related stuff
[General setup]
-> [Namespaces support]
->[UTS namespace]
-> [IPC namespace]
-> [User namespace]
-> [PID namespace]
-> [Network namespace]

[UTS namespace]
nodename + domainname -> uname(), gethostname() and getdomainname()
sethostname() + setdomainname()

[IPC namespace]
SysV IPC and message queues („ipc mechanism wich have no filesystem entry“)

[User namespace]
This allows processes to behave as if they were running as different users inside and outside the namespace -> a user id within the namespace is root, but outside is user tjohann

[PID namespace]
Isolate a process so that it cant kill or trace an process outside the namespaces

[Network namespace]
Isolate network devices

Mount namespace
Like chroot but more secure.