On Thu, Nov 27, 2014 at 11:19:18AM +0100, [email protected] wrote: > Il 26/11/2014 22:35, Stéphane Graber ha scritto: > > 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 > > 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 > > 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. > > > > 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 > > > it make sense and avoid the case where /dev is re-mounted and lxc is > then confused > > the only potential benefit I see (w/o knowing lxc code) in using > /dev/.lxc/ is hardlinking betweeen /dev and /dev/.lxc/container/
Which actually doesn't get you anything since nodes under /dev are char/block devices which do not have any content :) -- Stéphane Graber Ubuntu developer http://www.ubuntu.com
signature.asc
Description: Digital signature
_______________________________________________ lxc-devel mailing list [email protected] http://lists.linuxcontainers.org/listinfo/lxc-devel
