The vserver can't bind 0.0.0.0. The new set_ipv4root system call (named
after the chroot one) is setting one IP number in the current task_struct.
the system call accept only a transition from 0 to some IP. So like chroot()
once you do it in a process you are trapped.
The system calls affects both the bind() syscall and the connect() one (when
it lookup the route). Once an ipv4 root is set to x.y.z.w, the process (and children) can
bind (0.0.0.0) and it gets bind(x.y.z.w)
connect() without binding and they get coonect + bind(x.y.z.w)
bind (x.y.z.w) and it gets bind(x.y.z.w)
bind(another_ip) and it gets an error
connect + bind(another_IP) and it gets an error.
The ability to bind multiple time on a port has always been there. So using
this call, we limit the vserver to a single IP. The nice part is that this is
completly transparent to the vserver services. Services like apache, sshd, xinetd
sybase are running without any special configuration.
Btw, the v_xxx service (v_httpd, v_sshd) are simple wrapper to run service
in the main server without having to change their configuration so they
do not interfere. What they do is simply
/usr/sbin/chbind --ip eth0 /etc/rc.d/init.d/httpd $*
Also you can do the following
/usr/sbin/chbind --ip 126.96.36.199 some_command
and this effectivly prevent the "some_command" to do any IP network activity.
The set_ipv4root() syscall is not privileged at all. Its a one shot thing though :-)
For now, I have not tried to hide completly the fact that a vserver is a vserver. The only feature it has is that a vserver can have its own host and domain name. This was done because many service use this to setup some defaults and I wanted vservers to be as natural as possible configuration wise.
I could have added a couple featurism such as
private uptime hide the network device and fake a single one what else.
We will see as the need arise.
I also added the /sbin/vreboot command which talks with a socket /dev/reboot established by the rebootmgr service in the root server (one socket per vserver). This way a vserver can test its ability to properly shutdown and start. The reboot manager simply does
/usr/sbin/vserver the-vserver restart
this simply chroot to the vserver, selec the same security context, sets the ipv4root and then exec
Then it kills the remaining processes. To start it, it executes
In general, you reboot a vserver in 3 seconds :-)
--------------------------------------------------------- Jacques Gelinas <email@example.com> vserver: run general purpose virtual servers on one box, full speed! http://www.solucorp.qc.ca/miscprj/s_context.hc - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/