Subject: Re: [vserver] chbind the init process of the host (/sbin/init)
From: Herbert Poetzl <herbert@13thfloor.at>
Date: Tue, 2 Sep 2008 18:31:46 +0200

On Tue, Sep 02, 2008 at 09:07:29AM +0200, Manfred Heubach wrote:
> 
> Herbert Poetzl schrieb:
> > On Tue, Sep 02, 2008 at 12:31:44AM +0200, Manfred Heubach wrote:
> >   
> >> Hello,
> >>
> >> I'm experimenting with chbind in order to force the init process
> >> (/sbin/init) into a network context with 2 IPs (localhost and a single
> >> private IP).
> >>
> >> I call a script at systemboot called /sbin/vinit (via init=/sbin/vinit)
> >>
> >>   #!/bin/sh
> >>   exec /usr/sbin/chbind --nid 2 --ip 192.168.2.24 \
> >>   --ip 127.0.0.1 -- /sbin/init $@
> >>
> >> When using --nid 1 the script is working but the binding to the
> >> addresses doesn't work. The processes bind to any available IP.
> >>     
> >
> > that's expected, the nid=1 is the spectator network
> > context, which is supposed to see all network addresses
> > and doesn't restrict the user in any way
> >   
> ok. I expected something like that :-)
> >   
> >> When using --nid 2 the init process stops with the line telling me
> >> about it's usage (like when you give the wrong number of arguments)
> >> and I am ending up with a kernel panic.
> >>     
> >
> > this is most likely due to the fact that init isn't
> > the first process in your setup, e.g. it doesn't
> > get the 'magic' pid=1 assigned, and as init is written
> > in such way (most inits are, although there is no real
> > reason for that) that it check for its own pid, and
> > works differently (like telinit) when that pid is not
> > one ...
> >
> >   
> >> Is it actually possible to use chbind on the init process?
> >>     
> >
> > yes, that _is_ possible, if done properly
> >
> > the question is, why would you want to do that?
> >   
> I'm looking for a convenient and reliable way to bind my services on the
> host to a single IP and loopback. In the last years i sometimes had the
> problem that after an upgrade my wrapper script of e.g. postfix was
> overwritten by the orginal init script of the package maintainer. As a
> result the mta bound itself to all IPs (which was quite fun as all mail
> for the guests was now relayed to the host - which bounced it all - and
> having no way to relay himself - well something like a black hole was
> the result ...)
> > I hope you are aware that all your services, including
> > those to logon to the machine would be restricted to
> > those IPs for all ethernity ... i.e. it would be similar
> > to giving only those IPs to the host in the first place
> >   
> That won't be a problem as long as it is still possible to run the
> guests with their own IPs.

no, it won't as the script starting the guests,
or the sshd, which you use to logon, is already
restricted.

that is, why I consider 'init' the wrong place :)

best,
Herbert

> >> Otherwise I could build wrappers for my init scripts - 
> >> I used them with earlier versions - but it's always been a 
> >> bit improvised.
> >>     
> >
> > putting that into 'the' rc script or into separate 
> > scripts seems to me like the logical choice, as you
> > then could allow e.g. terminal logons or even ssh
> > logons to administrate the guests
> >
> >   
> >> To have the complete root server bound to a network context 
> >> and only bound to localhost and one ip address would be quite 
> >> handy.
> >>     
> >
> > well, why not just 'restrict' the host to those two
> > addresses and be done?
> >   
> Well, i *want* to restrict the host to those two addresses - but how?
> > HTC,
> > Herbert
> >
> >   
> >> Any ideas?
> >>
> >> The output of vserver-info is below.
> >>
> >> Best regards
> >> Manfred
> >>
> >> ---------------------------
> >> Versions:
> >>                    Kernel: 2.6.26-1-vserver-686
> >>                    VS-API: 0x00020303
> >>              util-vserver: 0.30.215; Jun  1 2008, 21:56:10
> >>
> >> Features:
> >>                        CC: gcc, gcc (GCC) 4.1.2 20061115 (prerelease)
> >> (Debian 4.                                              1.1-21)
> >>                       CXX: g++, g++ (GCC) 4.1.2 20061115 (prerelease)
> >> (Debian 4.                                              1.1-21)
> >>                  CPPFLAGS: ''
> >>                    CFLAGS: '-Wall -g  -O2 -std=c99 -Wall -pedantic -W
> >> -funit-at-                                              a-time'
> >>                  CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W
> >> -fmessage-length=0 -                                             
> >> funit-at-a-time'
> >>                build/host: i486-pc-linux-gnu/i486-pc-linux-gnu
> >>              Use dietlibc: yes
> >>        Build C++ programs: yes
> >>        Build C99 programs: yes
> >>            Available APIs: v13,net,v21,v22,v23,netv2
> >>             ext2fs Source: e2fsprogs
> >>     syscall(2) invocation: alternative
> >>       vserver(2) syscall#: 273/glibc
> >>                crypto api: beecrypt
> >>
> >> Paths:
> >>                    prefix: /usr
> >>         sysconf-Directory: /etc
> >>             cfg-Directory: /etc/vservers
> >>          initrd-Directory: $(sysconfdir)/init.d
> >>        pkgstate-Directory: /var/run/vservers
> >>           vserver-Rootdir: /var/lib/vservers
> >>