Quoting Stéphane Graber ([email protected]): > Hello, > > So I'm looking into how to rework lxc.autodev to apply properly to all > the cases we care about: > - Privileged containers started by root > - Unprivileged containers started by privileged root > - Unprivileged containers started by unprivileged root > - Unprivileged containers started by unprivileged user > > My understanding is that autodev currently creates /dev/.lxc and then > uses one directory per-container+lxc-path-hash under there, creates the > devices nodes and uses that as the container's /dev. > > My question is why the /dev/.lxc directory to begin with, wouldn't
Ok, after looking back through the code a bit, One advantage of the current method is that it doesn't need to use a tmpfs per container. If the host uses devtmpfs (which most do) then /dev/.lxc can just be a subdir, otherwise it needs to be the single tmpfs mount. This ensures that systemd will see a separate /dev and be happy. Another advantage of the current method is that the host can see the container's /dev more easily. Though I htink the existence of lxc-device suggests that we're ok. I mainly don't want to do anything that makes it harder for our eventual implementation of forwarding hotplug events into containers (as per the presentation at plumbers) > it make more sense to use LXC_PATH/<container>/dev, mount a tiny > tmpfs on that and then use it? This would have the advantage of having I guess one question is whether we think one more mount per container can become a scalability issue. Second question is whether systemd is happier if it sees that /dev is on devtmpfs. > the same path for privileged and unprivileged containers and avoid the > ugly lxcpath hash. > > > I believe the following setup would make a bit more sense and offer a > consistent behaviour: > - If not available or not a tmpfs, create LXC_PATH/<container>/dev and > mount a tiny tmpfs on it. Chown the path to the container's root uid/gid > and chmod to something sane. > - For all the nodes we care about, attempt to mknod them in there, on > failure, fallback to touch+bind-mount from real /dev. The improved consistency is appealing. > This would allow for the exact same code to be used for all 4 cases, for > the layout and location of the autodev tree to be entirely guessable > without requiring fancy hashing (making it easier for external tools to > interact with the autodev tree). > > As with the current implementation, the tree wouldn't be flushed on > container reboot but it would on container shutdown. > > > Does the above make sense or am I missing something about the design of > current autodev? > > Cheers > > -- > Stéphane Graber > Ubuntu developer > http://www.ubuntu.com > _______________________________________________ > lxc-devel mailing list > [email protected] > http://lists.linuxcontainers.org/listinfo/lxc-devel _______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
