101010.pl is one of the many independent Mastodon servers you can use to participate in the fediverse.
101010.pl czyli najstarszy polski serwer Mastodon. Posiadamy wpisy do 2048 znaków.

Server stats:

483
active users

#rootless

0 posts0 participants0 posts today
Replied in thread

Hi @lproven,
nice! I'm using several #CGI​s #RFC3875 for personal (scaled to n=1) web applications - be it (ephemeral) #QRCode qr.mro.name, #GeoHash mro.name/g/u28br conversion, a #nodb guestbook codeberg.org/jugendhacktlab.qd, a personal #ActivityPub server @aSeppoToTry or the hacky video-office-hours reservation system mro.name/sprechstunde. Once there even was a #HaveIBeenPwnd proof of concept blog.mro.name/2022/08/pwned-di.
They're #rootless deployments running on #shared #hosting (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

I had created a new #podman #rootless storage directory under /var/lib/containers/user/<name>, and _until now_ this worked without issue. Which was sheer luck it seems.

Now tried to start a container that uses musl, and it failed hard with

Error relocating /lib/ld-musl-x86_64.so.1: RELRO protection failed: No error

Some googling pointed me to #selinux again... adding the right context to the directories helps :D

Continued thread

So

(block traefik
(blockinherit container)
(allow process user_tmp_t ( sock_file ( write )))
(allow process container_runtime_t ( unix_stream_socket ( connectto )))
(allow process http_port_t ( tcp_socket ( name_bind )))
(allow process node_t ( tcp_socket ( node_bind )))
(allow process self ( tcp_socket ( listen )))
)

allows both access to the socket, and access to port 80/443.

Continued thread

Also, allowing a #rootless #podman #container to access to rootless #podman.sock file was fairly easy.

The following #selinux policy seems to allow that:

(block podman-socket
(blockinherit container)
(allow process user_tmp_t ( sock_file ( write )))
(allow process container_runtime_t ( unix_stream_socket ( connectto )))
)

Still half wondering why it needs write?

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! :)