digitalcourage.social is one of the many independent Mastodon servers you can use to participate in the fediverse.
Diese Instanz wird betrieben von Digitalcourage e.V. für die Allgemeinheit. Damit wir das nachhaltig tun können, erheben wir einen jährlichen Vorausbeitrag von 1€/Monat per SEPA-Lastschrifteinzug.

Server stats:

818
active users

#rootless

0 posts0 participants0 posts today
Replied in thread

Hi @lproven,
nice! I'm using several ​s for personal (scaled to n=1) web applications - be it (ephemeral) qr.mro.name, mro.name/g/u28br conversion, a guestbook codeberg.org/jugendhacktlab.qd, a personal server @aSeppoToTry or the hacky video-office-hours reservation system mro.name/sprechstunde. Once there even was a proof of concept blog.mro.name/2022/08/pwned-diy.
They're deployments running on (except qrcodes and HaveIBeenPwnd).

qr.mro.nameQR Code Generator

Instead of disabling unprivileged user namespaces plain and simple, Ubuntu since 24.04 restricts them with an AppArmor profile, which is known to be insufficient:
seclists.org/oss-sec/2025/q1/2

Yet, people writing code relying on unprivileged user namespaces have to deal with Ubuntu specifics where things don’t behave as documented. Latest example:
codeberg.org/guix/guix/issues/

How do folks deal with it?

seclists.orgoss-sec: Three bypasses of Ubuntu's unprivileged user namespace restrictions

Bueno, ya he eliminado todas las entradas del DNS con subdominios y solo he dejado dos wildcard, uno para lo expuesto y otro para lo interno

Para lo expuesto lo paso por npm (no me gusta que no tenga waf o mas opciones de seguridad), y para lo interno traefik tirando de las labels de los contendores

Por el camino he borrado todos los tunnels de cloudflare.

Siguiente paso, crear todos los usuarios y montar contenedores por tematica en usuarios aislados

For the past 12 days I was debugging why on earth #podman doesn’t want to build #rootless images.
Turns out:
1) DBUS_SESSION_BUS_ADDRESS has a value that’s not expected by podman.
2) since all my dotfiles are being grouped in a subdirectory. And have them linked to where their apps expect them to be. The #SELinux was preventing images from having the required permissions.
SELinux is one of main reasons why I use #Fedora , yet it can be a headache if you mess with it indirectly.

Aw, it works now

Networking in rootless Podman 4.x

If you're coming from 3.x, check if your /etc/containers/containers.conf has the new netavark/aardvark networking backend:

[network]
network_backend = "netavark"

The alternative is "cni", which is the default in 3.x. But it can break in root-less setups due to /etc/cni.d not being readable.

Check your system config with `podman system info | grep -A 8 "networkBackend"`:

networkBackend: netavark
networkBackendInfo:
backend: netavark
dns:
package: aardvark-dns-1.7.0-1.fc38.x86_64
path: /usr/libexec/podman/aardvark-dns
version: aardvark-dns 1.7.0
package: netavark-1.7.0-1.fc38.x86_64
path: /usr/libexec/podman/netavark
version: netavark 1.7.0

After reading a lot of Dan Walsh's articles on the matter, for the first time in my life I feel like understanding #containers, #podman, #docker, #rootful and #rootless, and how they differ in Docker vs. Podman. Which just means I misunderstood enough to be dangerous.

(tbf, I come from a probably not-so-common perspective of having had an okayish grasp of user namespaces but didn't grok podman.)

A little tip if you’re running in a rootless container on an immutable OS (like Fedora Silverblue) and have a tool (say Helix Editor – command: hx) installed in your “user” account but want to do, e.g.,

sudo hx /etc/hostname

Which would result in:

sudo: hx: command not found

Instead do:

(Fish) > sudo (which hx) /etc/hostname
(Bash) > sudo `which hx` /etc/hostname

Enjoy! :)