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

[confile] Add config for populate devices. #2160

Closed
wants to merge 1 commit into from
Closed

[confile] Add config for populate devices. #2160

wants to merge 1 commit into from

Conversation

lifeng68
Copy link
Contributor

Now the lxc provide the autodev hook to mknod in the container.
I think we should provide a way to make the same thing in config.

Signed-off-by: LiFeng lifeng68@huawei.com

@lxc-jenkins
Copy link

This pull request didn't trigger Jenkins as its author isn't in the whitelist.

An organization member must perform one of the following:

  • To have this branch tested by Jenkins, use the "ok to test" command.
  • To have a one time test done, use the "test this please" command.

Those commands are simple Github comments of the format: "jenkins: COMMAND"

Signed-off-by: LiFeng <lifeng68@huawei.com>
@brauner
Copy link
Member

brauner commented Feb 13, 2018

So one thing that immediately comes to mind is where this setup step is run. You're currently running it in lxc_setup() which runs in the container's namespaces. But this prevents unprivileged containers that are started by the root user from creating device nodes. So the setup process should likely take place somewhere else. We might have this work by doing it from the parent and having a helper process attach to the containers mount namespace and create the device nodes for us. That should work. But we need to discuss the sensibility of this whole approach first. And I want to admit up front: not a huge fan of the name lxc.populate.device. ;)

@hallyn
Copy link
Member

hallyn commented Feb 13, 2018

Was there a good reason to not just hook up the c->add_device_node and c->remove_device_node to a confile.c entry?

@brauner
Copy link
Member

brauner commented Feb 14, 2018

Yeah, we should use those two API functions. I just realized they need to be tweaked wrt to the devices cgroup. Meaning, we need to handle the unified hierarchy. But I can take care of that once this patchset lands.

@brauner
Copy link
Member

brauner commented Oct 14, 2018

So we'd still be interested in this but there hasn't been movement on this in a lot of months so I'm closing for now.

@brauner brauner closed this Oct 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants