Prove that a firewall may be done in the root environment to control
communication between vservers

Prove that multiple IP may be redirected to a single on so a vserver
may serve multiple IP even if it can bind to only one.

Find a clean way to chbind the root environment. Modifying /etc/rc.d/rc ?

Allow sharing the syslog server. syslogd supports the -a argument
but a hard link would do. After starting syslogd, just do a bunch
of hard link.

Apply the s_context to IPC operations

If we start sshd in the root environment with chbind, then it becomes
impossible to manage the vservers from it, since we are locked in one
ipv4root. Maybe root in s_context 0 would be allowed to switch the
ipv4root. This is what we did...

Is there a security flaw with /dev/pts. Maybe /dev/pts should be like
proc and only show stuff to processes from the same s_context. For now
the /dev/pts does not seem to work in a vserver (not enough capability ?)
and we must use the old /dev/pty ...

The new context_info in task_struct, being shared by all process in the
same context may be useful to enforce global settings such as
per context disk quota, memory usage, processes number. This is
probably easy to implement. struct context_info would contain
counters for various things and the limit would be settable by
a process with CAP_SYS_ADMIN. Well, so far so good. The new_s_context
is not privileged, so anyone can switch context and then starts all over
so to enforce per context limit, we have to control the ability
to call new_s_context. Instead of checking CAP_SYS_ADMIN in the effective
set, we could check it in the capbset instead. This way a normal user
can still switch context (with the default capbset).


