←back to thread

1101 points codesmash | 6 comments | | HN request time: 0.615s | source | bottom
Show context
miki123211 ◴[] No.45139800[source]
I've been dealing with setting up Podman for work over the last week or so, and I wouldn't wish that on my worst enemy.

If you use rootless Podman on a Redhat-derived distribution (which means Selinux), along with a non-root user in your container itself, you're in for a world of pain.

replies(13): >>45139949 #>>45139952 #>>45140035 #>>45140041 #>>45140112 #>>45140315 #>>45140558 #>>45140561 #>>45140736 #>>45140993 #>>45141204 #>>45141405 #>>45142506 #
1. Nextgrid ◴[] No.45140112[source]
I've never seen the benefit of rootless.

Either the machine is a single security domain, in which case running as root is no issue, or it's not and you need actual isolation in which case run VMs with Firecracker/Kata containers/etc.

Rootless is indeed a world of pain for dubious security promises.

replies(3): >>45140192 #>>45140341 #>>45141552 #
2. bbkane ◴[] No.45140192[source]
I see your point but I wouldn't let the perfect be the enemy of the good.

If I just want to run a random Docker container, I'm grateful I can get at least "some security" without paying as much in setup/debugging/performance.

Of course, ideally I wouldn't have to choose and the thing that runs the container would be able to run it perfectly securely without me having to know that. But I appreciate any movement in that direction, even if it's not perfect.

3. mbreese ◴[] No.45140341[source]
One of the major use cases was multi-user HPC systems. Because they can be complicated, it’s not uncommon for bioinformatics data analysis programs to be distributed as containers. Large HPC clusters are multi-tennant by nature, so running these containers needs to be rootless.

There are existing tools that fill this gap (Singularity/Apptainer). But, there is always friction when you have to use a specialized tool versus the default. For me, this is a core usecase for rootless containers.

For the reduced feature set we need from containers in bioinformatics, rootless is pretty straightforward. You could get largely the same benefits from chroots.

Where I think the issues start is when you start to use networking, subuids, or other features that require root-level access. At this level, rootless because a tedious exercise in configuration that probably isn’t worth the effort. The problem is, the features I need will be different from the features you need. Satisfying all users in a secure was may not be worth it.

replies(1): >>45145952 #
4. pkulak ◴[] No.45141552[source]
Rootless is nice because if you mount some directory in, all the files don't end up owned by root. You can get around that by custom building every image so the user has your user id, but that's a pain.
5. lmm ◴[] No.45145952[source]
> Large HPC clusters are multi-tennant by nature, so running these containers needs to be rootless.

I can't see how any kind of sensible security evaluation process would reach that conclusion. If you trust your users you don't need rootless, if you don't trust your users rootless containers aren't good enough. I suspect people do rootless because it seems easy and catches a few accidental mistakes rather than it being a legitimate security measure.

replies(1): >>45146490 #
6. mbreese ◴[] No.45146490{3}[source]
Think R1 research university or government lab level HPC clusters…

These are almost always multi-tennant with differing levels of trust and experience between users. The data processed here can often have data access agreements or laws that limit who can see what data. You can’t have a poorly configured container exposing data, for example. So, the number of people who have root access is very limited. Normal users running workflows would all be required to run code rootless.