Date: Wed 19 Feb 2003 - 23:16:00 GMT
I have an idea for solving the lack of console issue for fakeinit vservers.
I would like to run it past this list before I start coding.
The problem is basically this: /dev/console in a vserver should not be the
same device node as in the root host. If it was, then all contexts would
share the same real console which is both a security issue and messy with
regards to program output.
/dev/console can also not just be a regular file, because /sbin/init
assumes that it has the properties of a real or pseudo-terminal. When some
of the calls it makes (fcntl, tcgetattr, tcsetattr, tcflush etc) fail, init
gives up. It would be nice to:
a) give init what it thinks is a real console
b) store the output from this "console" for viewing from the root host or
c) not steal any valid pty/tty's (eg tty9, tty10) from the root host (this
d) not heavily modify the kernel to do this
We already have dynamic pty allocation available through /dev/ptmx and
/dev/pts. My idea is when starting a vserver, open a new pty and create
/vservers/$vs/dev/console with the same major and minor numbers. For all
intensive purposes init thinks this is ok and continues merrily on its way.
Anything written to this device is copied to a normal file somewhere for
viewing as desired.
There are a couple of issues (which I believe can be coded around):
* The pty creation should be done in the same context as the vserver so
that no other contexts can see it. However most vservers don't have the
capability of creating device nodes
* The process that creates the pty has to stay alive for the lifetime of
the vserver. It also cannot exec init directly because the first thing init
does is close all open file descriptors. We also want the file
descriptor/pty released when the virtual server is stopped.
I think this can be done with a small new binary, and some hacking of the
vserver script. I wouldn't mind hearing some feedback before I start
working on this so please mail your comments.