Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

about: correct references to runc #116

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

about: correct references to runc #116

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion pages/info/about.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,7 +69,7 @@ Singularity does not utilize a daemon process to manage the containers. While da

Additionally, securing a root owned daemon process which is designed to manipulate the host's environment becomes tricky. In currently implemented models, it is possible to grant permissions to users to control the daemon, or not. There is no sense of ACL's or access of what users can and can not do.

While there are some other container implementations that do not leverage a daemon, they lack other features necessary to be considered as reasonable user facing solution without having root access. For example, there has been a standing unimplemented patch to RunC (already daemon-less) which allows for root-less usage (no root). But, user contexts are not maintained, and it will only work with chroot directories (instead of an image) where files must be owned and manipulated by the root user!
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I see it:

  1. The first sentence would be more accurate if we add "...user facing HPC solution..."
  2. The second sentence is dated, as the user namespace patch has been merged into runc
  3. User contexts are not maintained in other solutions (inside the container, user seemingly becomes root) so this is accurate.
  4. As far as I know, no other container system leverages verifiable container image files. Without this, every file within the container must be owned by the user for it to be writable/modifiable/editable by the user. This is not the appropriate permissions of a root file system, so while this point is not wrong, it could be clarified.

Please feel free to challenge these points if you wish, but as I see it, aside from temporal modifications, this paragraph is accurate.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I know, no other container system leverages verifiable container image files. Without this, every file within the container must be owned by the user for it to be writable/modifiable/editable by the user. This is not the appropriate permissions of a root file system, so while this point is not wrong, it could be clarified.

Does "verifiable" in this context mean that you use a loopback device so that there's no extraction of the rootfs? If so, I agree most other runtimes don't do root filesystems in that way due to the concerns I outlined in our email thread (mainly related to the security of exposing the filesystem parsers to unprivileged users).

It should be noted that there are some container implementations that do not leverage a daemon and also do not require root privileges (either explicitly or with setuid binaries). One example of this is the runc project, which has support for ["rootless containers"](https://rootlesscontaine.rs/). Combined with other projects such as [umoci](https://github.com/openSUSE/umoci) this can be quite compelling for enterprise usecases. Unfortunately, due to the level at which runc and other such runtimes operate, as well as the feature set they provide, they are not usable directly for HPC workloads. In addition, they do not by default maintain the user context inside the container, which can cause some applications (including HPC applications) to misbehave.

## Use Cases

Expand Down