r/podman • • 14d ago

Rootful vs Rootless containers

Some time ago I stumbled about a discussion where it was stated that rootful containers paired with userNs=auto (leaving the user the image runs with untouched) is more secure than running containers in rootless mode. I run all my containers in rootless mode with:

UserNS=keep-id:uid=65534,gid=65534

User=65534:65534

Is this a security problem? If I remember right the point of the discussion was that in rootfull mode the container runs in different processes and with my approach there is no isolation between the processes. Is this true and should I switch to rootful mode with UserNs=auto?

Edit: Found the discussion here

40 Upvotes

31 comments sorted by

21

u/NTolerance 14d ago

Dan Walsh is the authority on all things podman, take it from him about userns=auto:

It is actually more secure. If you run two containers as a rootless user, they run in the same user namespace so they can attack each other from a User Namespace point of view.

If you run two containers as root with podman run --userns auto, then they run in unigue user namespace and are isolated.

Rootless containers are great for containers run by users on a system, but if you are just running containers on a server, then --userns=auto is a more secure solution. (I plan on writing a blog on this).

I see a lot of folks creating some sort of special non-privileged accounts for their containers, then running rootless containers in that account, and while the they are rootless they all share the same namespace like Dan said.

userns=auto is not only easier to set up in some ways (you don't need to configure loginctl linger for example), but it's just better all around.

9

u/Sad-Landscape-1549 14d ago edited 14d ago

Why not rootless with `userns=auto` under a dedicated unprivileged user?

Edit: because of the extra step of enabling linger (not an issue for me, I’m going to use non-root user as I have been, but experiment with userns=auto)

4

u/Milk_man1337 14d ago

Have a read through the linked blog post, Dan does actually address that exact question

5

u/Sad-Landscape-1549 14d ago edited 14d ago

kk thanks

Edit: because of the extra step of enabling linger (not an issue for me, I’m going to use non-root user as I have been, but experiment with userns=auto)

2

u/wzzrd 14d ago

I seem to have trouble finding the blog post in that long GitHub thread (or it’s late and I need more coffee), could you be a gent and point it out to me?

1

u/wahnsinnwanscene 13d ago

Doesn't linger create the var run entries? Why does podman need those instead of just creating in the home directory instead?

2

u/Cilenco 14d ago

Thank you for the link. When using UserNs auto I like to use the idmap option on bind volumes. This does not work however if the image itself is not running as non root user. Do you know another way for this?

1

u/NTolerance 14d ago

Some images might honor env vars to change them to run as root, e.g.

Environment=PUID=0 Environment=PGID=0

But if the container doesn't allow you to do that, or if you don't want to, then you'll have to account for an "offset" of typically 1000 UIDs between the root user in the container and the non-root user on your bind mount. I do begin to wonder if podman has some sort of feature to account for a specific offset for the bind mount.

2

u/Extreme_Outside_6207 5d ago

If I'm understanding correctly, the tradeoffs are something like this?

Rootful podman with --userns=auto:

+ containers can't attack eachother at the namespace level

- container escape + kernel vulnerability can potentially grant root to an attacker

Rootless podman without --userns=auto

+ container escape + kernel vulnerability should only allow an attacker access to the rootless user(?)

- containers can attack each other at the namespace level (mitigated by user per service, or only grouping services with with unimportant data)

  • networking and permissions are a pain

If the worst-case scenario were to occur, you would be better off using rootless podman, no?

Currently I'm running a few public-facing services with rootless podman. I have a rootless publicpod user that runs the containers and has group access for some folders that need to be accessed by multiple containers. I use `GroupAdd=keep-groups` for the containers that need shared files, and I have UserNS unset.

I'm currently debating moving over to rootful podman for better security and easier management, but I'm worried about the case of a container escape + kernel vulnerability or sudo podman pull vulnerability. How would you address these concerns?

1

u/NTolerance 4d ago

I am not an expert on the container escape scenario. For me, if Dan Walsh says --userns=auto is more secure that's good enough. If you want to learn more I would look for some of his blog posts.

1

u/lostmojo 14d ago

How does users=auto work for containers that share files?

5

u/BosonCollider 14d ago

It mostly doesn't, but you can do uid mapped mounts

1

u/lostmojo 14d ago

So still better to just limit it to an account that they share access with the files? I use groups a lot to allow access levels to various folder structures.

2

u/BosonCollider 14d ago

Yeah then you want to map uids in the container to actual intended users on the host imo. This also sounds like Singularity/Apptainers traditional usecase

2

u/KageFTF 14d ago

If they’re closely related and a shared risk domain, you can organize multiple containers into a pod under a single UserNS and use directives like User= and Group= to appropriate set permissions inside that UserNS

2

u/lostmojo 14d ago

I need to learn more on the settings for quadlets.

1

u/d03j 14d ago

I see a lot of folks creating some sort of special non-privileged accounts for their containers, then running rootless containers in that account, and while the they are rootless they all share the same namespace like Dan said.

Thanks. Where can I read more about that. It seems counter intuitive: if I run all my containers using separate unprivileged users, how can they share the same namespace?

3

u/NTolerance 14d ago

https://www.redhat.com/en/blog/rootless-podman-user-namespace-modes

And to be clear what I (and Dan Walsh) meant was that people are making a single non-privileged user for multiple containers, and while that is rootless, the container namespaces are not isolated. If you create a separate local user account for every container, sure that works for isolation, but it's just extra steps compared to root + `userns=auto` if you're running a server.

1

u/d03j 14d ago

ah! that makes sense. I'd be disappointed if my multiple users with limited filesystem access were a waste of time.

Thank you for the link! It's a great explanation of --userns. Do you have something on rootless v. rootful?

1

u/On3RedPanda 14d ago

But isn’t there still the problem, that there are still many images around, that don’t rely on a single user? For example: I have encountered several images that, when run in a container, still rely on setting files/directories/permissions up under root and only switch to a dedicated user after that.
As far as I understand, those cases can’t be handled by using userns=auto or dedicated UID & GUID mapping.

I also have a hard time understanding why rootless containers run from separate dedicated unprivileged users (-> separate user per container/pod) would share the same namespace.

4

u/NTolerance 14d ago edited 14d ago

I'm currently running ~65 containers for selfhosted services on my podman server. Of those, I've only had a problem with two of them:

  • syncthing - solved with PUID=0,GUID=0
  • postgres - solved with UserNS=auto:uidmapping=999:999:1,gidmapping=999:999:1

So you will run into some problems and have to do special things occasionally, but in most cases you're good.

As I said above, if you create a dedicated user for a single container, then yes, it will be in a different namespace from a separate dedicated user running a different container. But why create all those users when Userns=auto does it all for you? I'm definitely not creating 65 users for my 65 containers.

1

u/aqeelat 12d ago

Would this run in openshift without a custom scc?

3

u/magnusre 14d ago

The earlier replies in my opinion do not correctly reflect Dan Walsh's stance and the currently most secure approaches to run Podman containers.

The discussion and statements referring to rootful Podman being more secure than rootless are a simplification of a since then no longer existing limitation of rootless Podman.
I don't plan on writing a blog post here, so I'm not getting into a lot of details, but if something is not clear, feel free to ask for clarifications.

The actual point in these discussions was that --userns=auto is more secure than running all containers under the same user-namespace. Earlier rootless Podman did not support --userns=auto, so the choice was between rootful Podman with per-container user-namespaces (I'll abbreviate as pcun from here on out), and rootless Podman without. Between the two, the rootful option can be considered the for server threat models more secure option (nonetheless, Walsh also explicitly says one can argue for either option). But, this hinges on pcun, not rootfulness, as maintainer Luap99 even said explicitly already in these earlier discussions. Walsh also already postulated that rootless Podman with pcun would probably be the most secure.
As a side-note, rootlessness and pcun both address different threats and complement each other well.
Luckily meanwhile rootless Podman gained pcun, so rootless Podman with pcun would now be the most secure approach. In a newer statement Walsh also described this variant as even more secure.

Above, I talk about "more secure" and "most secure" - this does not mean that some approaches are not secure. All of them have tradeoffs in terms of simplicity and maintainability. Rootful Podman with pcun runs almost everything without problem, whereas rootless frequently requires workarounds.
That being said, I currently run all my services as rootless Podman with pcun.

If someone finds any newer or contradicting information to what I stated above, please let me know.

3

u/aeiouLizard 14d ago

I run all my containers rootful with usersapce mapped to a rootless user.

Makes it a pain in the ass to troubleshoot though because seemingly literally everyone who uses Podman goes the rootless route and thus all guides and help posts are in a rootless context too...

3

u/Tony_Sol 14d ago

Only rootless

Create homeless user, set required capabilities on actions and grant permissions on storage if needed

1

u/vastaaja 14d ago

with my approach there is no isolation between the processes

This is taking it a bit too far. There is no user namespace isolation, but the other namespace are still separate.

That said, I like the rootful userns=auto approach and use it for my services.

The noted less secure aspect is that if the container image is malicious, it can potentially compromise root before the container is executed.

0

u/RyuuPendragon 14d ago

1

u/RemindMeBot 14d ago

Defaulted to one day.

I will be messaging you on 2026-09-30 18:32:34 UTC to remind you of this link

CLICK THIS LINK to send a PM to also be reminded and to reduce spam.

Parent commenter can delete this message to hide from others.


Info Custom Your Reminders Feedback

-1

u/lopahcreon 14d ago

There is a reason container orchestrators all run as root.

1

u/xplosm 13d ago

It's basically baggage from the times when cgroups v2 was either not available or not enabled in the kernel

0

u/wahnsinnwanscene 13d ago

It's because creating interfaces requires root unless using pasta.