3 ms·

> The only new thing I’m seeing from this solution is the ability to create containers as an unprivileged user, which for most scenarios I tend to view as a non

by symkat 8y ago

> The only new thing I’m seeing from this solution is the ability to create containers as an unprivileged user, which for most scenarios I tend to view as a non-issue. Or am I misunderstanding that? I believe you're mislabeling it as a non-issue, it seems to be the core problem they're trying to solve: From the blog[0]: > Yes, we all know that containers run unprivileged processes; but creating and running the containers themselves requires root privileges at some point. > What is the awesome sauce we all gain from this? > Well judging by the original GitHub issue about unprivileged runc containers, the largest group of commenters is from the scientific community who are restricted to not run certain programs as root. [0]: https://blog.jessfraz.com/post/getting-towards-real-sandbox-containers/ https://blog.jessfraz.com/post/getting-towards-real-sandbox-...

mroche 8y ago
I did read the blog post, but it all seemed about running containers as unprivileged users. Being able to create is what I’m saying is a non-issue, because it only saves a single convience step of not having to upload a container built elsewhere to a cluster. And tools like Singularity have online tools (Sylabs Library, Singularity Hub) which offer remote builders for users that don’t have privileges anywhere (which is hard to find) and don’t want to build containers locally. You can then pull and run the produced container from the Singularity executable without needing root access. An alternative is a cluster could set up a single machine that gives users sudo access only on the Singularity executable and prevent the ability to bind mount, therefore creating a relatively secure build environment on-premise. However, security matters more than conviencence for HPC clusters, so we’re more inclined to tell users “do it yourself” than give them any loophole in the system. Singularity already solves the unprivileged running of containers. Unless binctr is doing something that provides a different kind of unprivileged access? I’m not trying to be thick headed, but I’m just not connecting the dots on what’s so special about this.
- justinsaccount 8y ago
  > I’m just not connecting the dots on what’s so special about this. It's not. binctr is not special. Singularity is not special either. They are both tools that do similar things.

by symkat 8y ago

mroche 8y ago

I did read the blog post, but it all seemed about running containers as unprivileged users. Being able to create is what I’m saying is a non-issue, because it only saves a single convience step of not having to upload a container built elsewhere to a cluster. And tools like Singularity have online tools (Sylabs Library, Singularity Hub) which offer remote builders for users that don’t have privileges anywhere (which is hard to find) and don’t want to build containers locally. You can then pull and run the produced container from the Singularity executable without needing root access. An alternative is a cluster could set up a single machine that gives users sudo access only on the Singularity executable and prevent the ability to bind mount, therefore creating a relatively secure build environment on-premise. However, security matters more than conviencence for HPC clusters, so we’re more inclined to tell users “do it yourself” than give them any loophole in the system. Singularity already solves the unprivileged running of containers. Unless binctr is doing something that provides a different kind of unprivileged access? I’m not trying to be thick headed, but I’m just not connecting the dots on what’s so special about this.

justinsaccount 8y ago
> I’m just not connecting the dots on what’s so special about this. It's not. binctr is not special. Singularity is not special either. They are both tools that do similar things.