[lxc-devel] Questions about lxc.autodev

[Stéphane Graber]

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

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20141126/a42c0ee7/attachment.sig>