WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: PodMan, the future for rootless containers  (Read 182 times)

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 935
PodMan, the future for rootless containers
« on: September 28, 2025, 09:12:52 AM »
Docker is the past for containers. Even if client "docker" can run as rootless (without root privileges) on host (laptop), but its engine "dockerd" MUST be run as ROOT on the host (dangerous).

The future for managing containers (builds + runs + distributes etc) is "podman". BOTH its engine and container builder (run/build/delete/commit/ etc) runs rootLESS, so better protection.
The drill is similar like:
1. grab an image (already build for you by others, even signed) from dedicated servers (named repository).
 -- or you can build yourself from pieces, the same like Tinyocre core.gz is done.
 -- FYI: the image could be just a tarball, what matters is to have inside the root files (like root.gz) AND the package manager (like tce-load).

2. the container is then build from this image as a base + extra layers (you add using the package manager, for example). All is automatically, next to nothing to learn (joke of course).

Example-1: run a busybox (dynamically linked to libc) in a container.
so, one command to "download" a rootfs one time only (because will be cached on host) and auto-open a terminal with busybox 1.37
Code: [Select]
podman run -rm -it docker.io/busybox
Example-2: run dillo (dynamically linked to musl) in a container.
two command only, one to download an already build minimal Alpine-Linux with its apk (package manager), and a second command from inside the container, to run dillo, its GUI will be seen on host.

Code: [Select]
podman run --rm -it -e DISPLAY -v $XAUTHORITY:/root/.Xauthority:ro -v /tmp/.X11-unix:/tmp/.X11-unix:ro --net=host docker.io/alpine
(from container): apk add dillo & dillo

FYI:
 "-rm" means remove container (but keep it basic image) so you loose "dillo and its dependency" but start fresh next time;
 "-it" means open a terminal with a shell
 "apk add dillo", is like tce-load -iw dillo.tcz

The great thing is that you can SAVE what you already build as a NEW image, and next time you continue to build over this "layer". Example: in the container with dillo you can add "netsurf" without downloading initial Apline and without adding dillo, because all is cached locally, layered.

So basically you can run in parallel many containers: one with just dillo inside, other with just GCC (tools for compile anything), or even a full OS inside container. All container are isolated between them and between host by default. But of course you can mount some "volumes" (basicaly host folder) to output what you created inside the container.

Enjoy podman (= Pod Manager, with pod = groups of containers, and container = image + layers like Qemu QCOW).
« Last Edit: September 28, 2025, 09:36:34 AM by nick65go »

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 935
Re: PodMan, the future for rootless containers
« Reply #1 on: September 28, 2025, 11:44:38 AM »
As this forum is for TC users, I did not touch Podman capabilities like system-d, SELinux, kubernets, podman GUI, etc

But podman has a very comprehensive documentation and tutorials, and man pages etc.
https://docs.podman.io/en/latest/
https://docs.podman.io/en/latest/markdown/podman-run.1.html
https://github.com/containers/podman

FYI: a lot of (bullshit) marketing, but very strong points about Podman versus Docker
https://www.redhat.com/en/topics/containers/what-is-podman

"you can also take advantage of Podman Desktop, a graphical user interface (GUI) for using Podman in local environments,
 - optionaly, Podman launches each container with a Security-Enhanced Linux (SELinux) label...
 - Users can easily switch between them by aliasing Docker to Podman (alias docker=podman) and vice versa. -easy learning curve
- using Docker during the development stage and transferring their program to Podman in runtime environments 
- Podman is best suited for developers running containers without Kubernetes..."
« Last Edit: September 28, 2025, 11:51:11 AM by nick65go »

Offline gadget42

  • Hero Member
  • *****
  • Posts: 948
Re: PodMan, the future for rootless containers
« Reply #2 on: Today at 01:34:31 AM »
i found this webpage interesting and it does reference gitlab but doesn't reference shithub:

https://bluelight.co/blog/how-to-choose-a-container-registry

https://hjgit.org/static/guide.html

https://shithub.us/

20250929-0050am-cdt-usa-modified: adding *no affiliation(s) with _any_ of the above*
« Last Edit: Today at 01:50:27 AM by gadget42 »
** WARNING: connection is not using a post-quantum kex exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 935
Re: PodMan, the future for rootless containers
« Reply #3 on: Today at 09:47:20 AM »
i found this webpage interesting and it does reference gitlab ...
So? did you find (or want to share) something constructive for TC users ?
Excepting the "classics" -- like "chroot" poor man method, or heavy RAM intensive VM (virtual machines) like Qemu --, have you anything better, smaller, smarter that podman?
I do not give a shit about "Container Registry" servers, which is dedicated for developers (which I am not) to shared their work, faster debugging, continuous distribution, etc.

My share was about a strong method, accessible to common users, because: runs  on relatively cheap hardware, low/ re-used resources, fast learning curve, no need for SELINUX or systemd (but nice if you have) etc. But most important (at lest for me) the security -- to run ISOLATED any single appliance (like dillo, or gnumeric),without "polluting" the host machine. Confidently to test / run any "insecure" free software you grab for free from internet "friends".
« Last Edit: Today at 09:49:46 AM by nick65go »

Offline nick65go

  • Wiki Author
  • Hero Member
  • *****
  • Posts: 935
Re: PodMan, the future for rootless containers
« Reply #4 on: Today at 11:45:37 AM »
Maybe my mistake was that I was not clear / explicit in the TITLE about my (selfish) interest in LOCAL (runs on laptop) containers, whatever they could be (chroot, Virtual Machines, kernel names-pace isolation, etc).
- chroot is not very secured; is fast and not so laboriously to do it (just mount few folders).
- docker is the standard industry; overwhelming options to build + run containers + distribute them; but its engine runs (in 99.9% cases) as root in the host.
- podman is the new kid in the sandbox yard. it has ALL of docker CLI (command line parameters) to run a container, and OPTIONS to build a container / image from a config file.

The main advantage of containers (which is basically an image, or a tarball group of files) versus VM (virtual machines, qemu) is that all containers share the same host kernel, not fake disk HDD (which use block-sectors + file system driver, so waste space), no USB/CDROM (just mount shared folders from host). And use protected uid+gid (=different on guest/container versus the host) so the malicious app from container has no user rights on host. ...

Anyway too much to explain the basics of Linux security protection, because we go over from DAC (Discretionary Access Rights, like r/w/x) into MAC (Mandatory Access Rights, like SElinux, AppArmour).

Offline hiro

  • Hero Member
  • *****
  • Posts: 1240
Re: PodMan, the future for rootless containers
« Reply #5 on: Today at 06:37:18 PM »
i agree chroot doesnt add much separation, and i agree docker's security model is mostly non-existent, but i do not agree that podman's "rootless" "innovation" gets you where you want to be either.

the complexity they are adding to the kernel for podman's "security" framework is hard to manage, the kernel has not been built with this in mind, and the result is mostly hacks that nobody understands, what seems like a useful abstraction to the user is in fact a huge leaky mess and nobody should rely on it being safe.

it might seem that since podman consists of many layers, and many people wasted much time to build these, that you have done enough research to pick this software and to sleep in peace at night. but that is not the case.

qemu/kvm style virtualization might also not have been ever intended for security, and yet it's much closer to what you are expecting here.

if you *really* cared about security though, you'd separate your security domains into multiple dedicated machines and ignore all promises by container and virtualization people.
process virtualization is great if you don't want an application to crash your whole system (all other applications, your kernel, ...).

containerization is a hack around the fact that dynamic linking has failed everyone: poor glibc man's static linking.