Hi,
Reading the kernel documentation of devpts, I got the impression that if
the host uses the "legacy" devpts mode, root in a container can always
mount its devpts instance. Is this really so? If yes, it might be
worth noting somewhere near the lxc.pts option. And a kernel option to
disable legacy devpts mounts...
(Unrelated note: lxc.console is totally undocumented.)
A related note: if access to /dev/ptmx (c 5:2) is denied by cgroup, my
application container can't even start with a rather puzzling error:
lxc-start: File exists - failed to symlink '/dev/pts/ptmx'->'/dev/ptmx'
The symlink goes the other way, and the recommended setup is
/dev/ptmx -> pts/ptmx (a relative link, but it probably doesn't matter).
Anyway, I'd rather lxc not modify my rootfs, and especially not without
telling me about it. I don't understand why devpts.txt favors symlinks
to bind mounts, that would be good to know.
And yes, /dev/ptmx is present in my (read-only) root filesystem, and
access("/dev/ptmx", F_OK) seems to fail if cgroup denies access. Using
access() is usually frowned upon because it's racy, anyway... To
conclude this incoherent babbling: does setup_pts() in conf.c do
anything which couldn't be easily done by mount entries and/or modifying
the rootfs beforehand? If this complexity is really needed, we really
should document it to some extent.
One last point: the out: label in setup_pts() should precede the INFO()
call, shouldn't it?
--
Cheers,
Feri.
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Lxc-devel mailing list
Lxc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lxc-devel
