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.

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

Closed
flx42 opened this issue Dec 13, 2017 · 8 comments
Closed

[RFE] Support configurations without root mapping #2033

flx42 opened this issue Dec 13, 2017 · 8 comments

Comments

@flx42
Copy link
Contributor

flx42 commented Dec 13, 2017

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:

lxc.idmap = u 1000 1000 1
lxc.idmap = g 1000 1000 1

lxc.init.uid = 1000
lxc.init.gid = 1000

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:

$ lxc-create -t download -n xenial -- --dist ubuntu --release xenial --arch amd64
lxc-create: xenial: conf.c: chown_mapped_root: 2825 No uid mapping for container root

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.

@brauner
Copy link
Member

brauner commented Dec 14, 2017

@stgraber, @hallyn I'd like an opinion here.

@hallyn
Copy link
Member

hallyn commented Dec 14, 2017

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.

@flx42
Copy link
Contributor Author

flx42 commented Dec 14, 2017

uid 1000 is fine.
In this use-case, the whole container / could be mounted read-only actually, just my home would be writable.

@hallyn
Copy link
Member

hallyn commented Dec 15, 2017

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.

@brauner
Copy link
Member

brauner commented Dec 15, 2017

This sounds like something worth doing!

@brauner
Copy link
Member

brauner commented Jan 2, 2018

@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 lxc_setup() which require us to be root in the container's user namespace. For example, all lxc.mount.entry operations that use options that require root would fail. This e.g. includes --no-mtab and of course --type which would prevent the container from mounting it's own devpts instance which it very likely wants to do. Additionally, we're only allowed to write a id mapping once so we can't update it after the fact. One solution however, would be to dynamically allocate a mapping for the container root user and then to unshare another user namespace and write the second mapping. @hallyn, any other ideas?

@brauner
Copy link
Member

brauner commented Jan 2, 2018

Actually, I might have an idea.

brauner pushed a commit to brauner/lxc that referenced this issue Jan 2, 2018
- mapped_hostid_entry()
- idmap_add()

Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner pushed a commit to brauner/lxc that referenced this issue Jan 2, 2018
Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner pushed a commit to brauner/lxc that referenced this issue Jan 2, 2018
Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner pushed a commit to brauner/lxc that referenced this issue Jan 2, 2018
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>
brauner pushed a commit to brauner/lxc that referenced this issue Jan 2, 2018
Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
@brauner
Copy link
Member

brauner commented Jan 3, 2018

@flx42, here's a POC:
asciicast

brauner pushed a commit to brauner/lxc that referenced this issue Jan 3, 2018
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>
brauner pushed a commit to brauner/lxc that referenced this issue Jan 4, 2018
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>
brauner pushed a commit that referenced this issue Jan 19, 2018
- mapped_hostid_entry()
- idmap_add()

Closes #2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner pushed a commit that referenced this issue Jan 19, 2018
Closes #2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner pushed a commit that referenced this issue Jan 19, 2018
Closes #2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner pushed a commit that referenced this issue Jan 19, 2018
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>
brauner pushed a commit that referenced this issue Jan 19, 2018
Closes #2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
brauner pushed a commit that referenced this issue Jan 19, 2018
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>
geaaru pushed a commit to geaaru/lxc that referenced this issue Jul 4, 2018
- mapped_hostid_entry()
- idmap_add()

Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
geaaru pushed a commit to geaaru/lxc that referenced this issue Jul 4, 2018
Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
geaaru pushed a commit to geaaru/lxc that referenced this issue Jul 4, 2018
Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
geaaru pushed a commit to geaaru/lxc that referenced this issue Jul 4, 2018
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>
geaaru pushed a commit to geaaru/lxc that referenced this issue Jul 4, 2018
Closes lxc#2033.

Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
geaaru pushed a commit to geaaru/lxc that referenced this issue Jul 4, 2018
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants