[lxc-devel] Questions about lxc.autodev

[Serge Hallyn]

Quoting Stéphane Graber (stgraber at ubuntu.com):
> 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
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel