...making Linux just a little more fun!
[ In reference to "Virtualizing without Virtualizing" in LG#150 ]
Jim Dennis [answrguy at gmail.com]
Kapil forgot at least one important term in his "EULA(1)":
* The software to be run can share the network interface state with the parent and all siblings.
In particular, we have have to recognize that only one process (family) on a given machine can bind to a given port to accept incoming requests. For example, you can have only one sshd listening on port 22 on any given interface, and one listening on the "catchall" interface. If I have one sshd listening on the catchall and one listening on the address bound eth0:0 (both on TCP port 22), then any incoming request for that one address will go to the second process; any other incoming requests will go to the first one.
(It's fairly rare to configure a system with a mixture of processes listening on specific and catchall addresses, BTW; but it is possible).
The key point here is that the chroot "virtualization" is not amenable to hosting networking services, unless you can arrange some way to dispatch the incoming connections to their respective chroot jailed processes on different ports or IP aliases.
However, overall, I have been recommending chroot as a "super lightweight virtualization" model for many years. It only virtualizes the file/directory structure, but that's often sufficient for development work, for example.
JimD (AnswerGuy emeritus?)
Jim Dennis [answrguy at gmail.com]
Oh, yeah ... and two other follow ups:
* (1) --- I like this notion of a EULA for a "HOWTO" --- to state the pre-conditions for using it.
Also, the use of X applications that are in chroot jails requires that we use something like *mount -o bind /tmp ${CHROOT_PATH}/tmp* or that we use an *ssh -X *into the chroot jail
... or otherwise arrange to treat the X session as though it were on a separate system from our chroot jail. You probably also need to arrange either a bind mount for /home
... or to copy .Xauthority files or use *xauth extract ... | xauth merge
... *to copy your X cookies (authorization tokens) around.
The easiest way are the bind mounts, because X applications will use the UNIX domain socket (/tmp/.X11-unix/X0, and so on) to contact their server when DISPLAY is set to something like :0.0. If DISPLAY is set to *localhost:*0.0, then that forces the X libraries to initiate an Internet domain socket connection (to 127.0.0.1, TCP port 6000). This will fail on most modern Linux systems in their default configurations, since they now default to -nolisten tcp for security reasons. Similarly, the bind mounts of /home to ${CHROOT_PATH}/home allow Xlib to find the MIT magic cookies in their usual place.
(The other hacks I've described are based on contortions I had to develop before --bind mount options were available in Linux; when I really didn't want to impose the overhead of loopback NFS mounts --- which are truly ugly!)
On Fri, May 2, 2008 at 12:21 PM, Jim Dennis <[email protected]> wrote:
Kapil Hari Paranjape [kapil at imsc.res.in]
Hello,
On Fri, 02 May 2008, Jim Dennis wrote:
> * (1) --- I like this notion of a EULA for a "HOWTO" --- to > state the pre-conditions for using it.
I thought it was pretty clever, too 
!
> Also, the use of X applications that are in chroot jails requires
> that we use something like *mount -o bind /tmp ${CHROOT_PATH}/tmp*
The "schroot" system takes care of creating such bind mounts. You need to provide the list of such mounts in its configuration. I mentioned this for "/dev/snd" but forgot to mention it for "/tmp" which as you say is necessary for X (and some other sockets).
Thanks for pointing this out.
Regards,
Kapil. --
Jim Dennis [answrguy at gmail.com]
I assume you're already handling it for /proc as well?
(It gets uglier over time, so I now need to do bind mounts for /sys and /dev/, as well as the others as mentioned).
Kapil Hari Paranjape [kapil at imsc.res.in]
Hello,
On Fri, 02 May 2008, Jim Dennis wrote:
> Kapil forgot at least one important term in his "EULA(1)": > > * The software to be run can share the network interface state with > the parent and all siblings
Indeed. Extra configuration is required for all overlapping services. It is possible to create a "top-level" daemon that binds only to a.b.c.d:p and an "schroot" daemon that binds to x.y.z.w:q. However, it is much easier/safer to handle this separation using "vservers" or "jails" (BSD) or "containers" (Solaris).
The extra EULA statement should be:
* The services in the chroot do not overlap with those
outside the chroot.
> However, overall, I have been recommending chroot as a "super > lightweight virtualization" model for many years. It only > virtualizes the file/directory structure, but that's often > sufficient to development work, for example.
Absolutely. This is what I set out to "prove" in the article. We should dispel the idea that "chroot" is only used for security. In fact, when separation is required for security, it is probably much better to use "stronger" virtualization such as those mentioned above or Xen or qemu etc.
> JimD > (AnswerGuy emeritus?)
Emeritus, without a doubt. Nice to hear from you.
Regards,
Kapil. --