From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Thu 20 Feb 2003 - 00:26:49 GMT
On Thu, Feb 20, 2003 at 12:16:00AM +0100, mark.lawrence_at_holcim.com wrote:
> Hi,
Hi Mark!
> 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.
why not make the console (vc layer) vserver independant?
each server gets it's own set of vcs unless specified
that the physical vcs should be shared ...
if it is required (or useful) that the spectator context
(context 1) or even the physical context, access these
vcs, they could be made visible in these contexts ...
(this is already partially done)
> /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
that would be easy, take any vc/pty and init should
be happy ...
> b) store the output from this "console" for viewing from the root host or
> vserver
this sounds pretty smart, but usually leads to ugly
consequences ...
- needs a logger (like syslog)
- requires special permissions (for the vserver)
- what about partial console writes
- how to synchronize/propagate?
> c) not steal any valid pty/tty's (eg tty9, tty10) from the root host (this
> wouldn't scale)
I think this shouldn't be such an issue, because
the number of virtual consoles could be easily
raised, and I do not know anybody with more than
25 vcs open (usually there would be 4-8) ...
> d) not heavily modify the kernel to do this
small changes with big gains are always the
best solutions ...
> 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.
if you want to capture all console logging or something
similar, why N processes listening on N devices/ptys?
why not tagging the information with the context number
and processing everything in one logger process?
> 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
this sounds like a sleeping security issue to me ...
> * The process that creates the pty has to stay alive for the lifetime of
> the vserver.
what if it dies? what about cleanup?
> 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.
what if something extremely bad happens to the vserver?
> 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.
some topics not mentioned:
- what about a vserver devfs? could be beneficial ...
- why not completely virtualizing the device layer?
- what about a special vserver init version?
(I know, I know because we would modify the system
running within the vserver, but why not? we already
modify at least the /dev entries and reboot/etc ...)
I hope this doesn't sound like a "forget it" or
"what an absurd proposal?", because basically I like the
idea ...
hope this is of any use,
Herbert
> Thanks, Mark.
> --
> mark.lawrence_at_holcim.com