31
submitted 3 days ago by [email protected] to c/[email protected]

Hi all !

As of today, I am running my services with rootless podman pods and containers. Each functional stack gets its dedicated user (user cloud runs a pod with nextcloud-fpm, nginx, postgresql...) with user mapping. Now, my thought were that if an attack can escape a container, it should be contained to a specific user.

Is it really meaningful ? With service users' home setup in /var/lib, it makes a lot of small stuff annoying and I wonder if the current setup is really worth it ?

you are viewing a single comment's thread
view the rest of the comments
[-] [email protected] 19 points 3 days ago

Af an attack can escape a container a lot of companies worldwide are going to need to patch a 0-day. I do not expect that to be part of my threat model for self-hosted services.

[-] [email protected] 10 points 2 days ago* (last edited 2 days ago)

Woah, no. Sure escaping via a kernel bug or some issue in the container runtime is unexpected, but I "escape" containers all the time in my job because of configuration issues, poorly considered bind mounts, or the "contained" service itself ends up being designed to manage some things outside of the container.

Might be valid to not consider it with the services you run, but that reasoning is very wrong.

[-] [email protected] -1 points 1 day ago

Companies don't typically host multiple containers on the same host. So having a different user for them is less important than securing the connection between machines, since a given biat isn't particularly interesting. Attackers will still try to break out, so they have a backup.

As a self-hoster, you typically do the opposite. You run multiple services on the same host, and the internal network isn't particularly secure. So you should be focusing more on mitigating issues, and having each service run as an unprivileged user is one fairly easy way to do that.

[-] [email protected] 2 points 1 day ago

Companies do run multiple containers/pods on the same host. That is what Kubernetes does

[-] [email protected] 1 points 20 hours ago

Sure, but those will usually be pieces of an app on the same host, not whole apps. Like for an inventory management app, you might have the auth server and its database on one host, the CRUD app and its database on another, and the report server, its database, and a replica of the CRUD db on another. And I use the term "host" broadly enough to include VMs on the same physical hardware. And these hosts will have restricted communication between each other.

At least, that's how I've seen it done.

Self-hosters will generally run multiple full apps on one host. It's a different setup.

[-] [email protected] 3 points 3 days ago

I guess I should define my threat model first. Your answer pulls me towards a single user though

this post was submitted on 15 Jul 2025
31 points (94.3% liked)

Selfhosted

49549 readers
458 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS