Re: Bug#100668: apt should allow to select from more 'sources.list' files
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.
Reply to: