-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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.
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
[RFE] Support configurations without root mapping #2033
Comments
I can see cases where this would make sense, but the lxc-create example you show actually may not be one of them. What do you want things like /bin/sh to be owned by - user nobody, or uid 1000? If user nobody, then at least while running the creation template you'll need to have uid 0 mapped. |
uid 1000 is fine. |
I'm fine with the feature. I suspect we may want to make it easier (or document the easiest way) to specify a differnet uidmap for lxc-create than for lxc-execute. So lxc-execute would just have b:$(id -u):$(id -u):1, but lxc-create would also have b:0:100000:1. Then system files would be owned by user nobody in the container, protecting its integrity. |
This sounds like something worth doing! |
@flx42, @hallyn, so I've been thinking about this a little more. There is one problem I've noticed which is that we perform a bunch of operations in |
Actually, I might have an idea. |
- mapped_hostid_entry() - idmap_add() Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
If no id mapping for the container's root id is defined try to us the id mappings specified via lxc.init.{g,u}id. Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
@flx42, here's a POC: |
When fully unprivileged users run a container that only maps their own {g,u}id and they do not have access to setuid new{g,u}idmap binaries we will write the idmapping directly. This however requires us to write "deny" to /proc/[pid]/setgroups otherwise any write to /proc/[pid]/gid_map will be denied. On a sidenote, this patch enables fully unprivileged containers. If you now set lxc.net.[i].type = empty no privilege whatsoever is required to run a container. Enhances lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Felix Abecassis <fabecassis@nvidia.com> Cc: Jonathan Calmels <jcalmels@nvidia.com>
When fully unprivileged users run a container that only maps their own {g,u}id and they do not have access to setuid new{g,u}idmap binaries we will write the idmapping directly. This however requires us to write "deny" to /proc/[pid]/setgroups otherwise any write to /proc/[pid]/gid_map will be denied. On a sidenote, this patch enables fully unprivileged containers. If you now set lxc.net.[i].type = empty no privilege whatsoever is required to run a container. Enhances lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Felix Abecassis <fabecassis@nvidia.com> Cc: Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
- mapped_hostid_entry() - idmap_add() Closes #2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes #2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes #2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
If no id mapping for the container's root id is defined try to us the id mappings specified via lxc.init.{g,u}id. Closes #2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes #2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When fully unprivileged users run a container that only maps their own {g,u}id and they do not have access to setuid new{g,u}idmap binaries we will write the idmapping directly. This however requires us to write "deny" to /proc/[pid]/setgroups otherwise any write to /proc/[pid]/gid_map will be denied. On a sidenote, this patch enables fully unprivileged containers. If you now set lxc.net.[i].type = empty no privilege whatsoever is required to run a container. Enhances #2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Felix Abecassis <fabecassis@nvidia.com> Cc: Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
- mapped_hostid_entry() - idmap_add() Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
If no id mapping for the container's root id is defined try to us the id mappings specified via lxc.init.{g,u}id. Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Closes lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
When fully unprivileged users run a container that only maps their own {g,u}id and they do not have access to setuid new{g,u}idmap binaries we will write the idmapping directly. This however requires us to write "deny" to /proc/[pid]/setgroups otherwise any write to /proc/[pid]/gid_map will be denied. On a sidenote, this patch enables fully unprivileged containers. If you now set lxc.net.[i].type = empty no privilege whatsoever is required to run a container. Enhances lxc#2033. Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> Cc: Felix Abecassis <fabecassis@nvidia.com> Cc: Jonathan Calmels <jcalmels@nvidia.com> Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Let's say I'm only interested in running unprivileged application containers.
Also, I don't want to be
root
inside the container since I want to bind-mount my$HOME
folder and have everything work similarly as outside the container as a user (i.e., it's just a way to just swap the distro I'm using).I could achieve this by having the following in
default.conf
:However, there seems to be a bunch of places in the code where it is rejected. For example, this is the first problem I'm having:
I've quickly removed all these tests in the code and it seems to work, but it's a pretty huge change that touches many parts of the code, so I'll let @brauner handle it ;). If you think that's a valid use case, of course.
The text was updated successfully, but these errors were encountered: