On Wed, 13 Jun 2001, Jason Gunthorpe wrote:
> On Wed, 13 Jun 2001, Alexander Viro wrote: > > > On 2.4 it's trivial without any changes to apt-get. > > Bind mounts work on files? How fancy. Sure, they do. And yes, it is intended behaviour. Actually, the rule is the same as with rename - you can't bind directory on non-directory and vice versa. Both for bindings and usual mounts - just that for usual mounts the thing you are binding to mountpoint (i.e. root of the tree you are mounting) will be a directory. It's pretty useful - you can use them as "symlinks done right". Unlike symlinks they are not stored on the filesystem (well, aside of their presense in /etc/fstab or whatever script you've used to create then ;-) That allows, for example, to have them set on per-host basis even on shared filesystems. Or on read-only ones. Moreover, unlike symlinks they are evaluated when you set them. So you can bind (from outside of chroot jail) /home/jail/dev/null to /dev/null, etc. Another trivial example: % mkdir /tmp/chroot % cp /usr/bin/gcc gcc % cat >~/gcc.wall <<EOF #!/bin/sh exec ~dsource/gcc -Wall $* EOF % chmod +x gcc.wall % su - Password: # for i in / /usr /tmp /var /home /usr/local /proc /dev/pts; do > mount --bind $i /tmp/chroot/$i; > done # mount --bind ~dsource/gcc.wall /usr/bin/gcc # chroot /tmp/chroot # su - dsource % and now all processes in chroot get gcc replaced with a wrapper, but everything out of chroot lives undisturbed. Sure, you can do that without file bindings, but it will take much more efforts, not to mention the disk space. Besides, try to do that with /usr on read-only (and possibly shared) filesystem... BTW, overhead of binding is less than that of a symlink; it's the same as for traversing normal mountpoint.
