On Fri, 16 Feb 2001, Bruce Evans wrote:

> > What is it you're trying to accomplish here, exactly?  Is it prevent paths
> > >MNAMELEN to be used as targets of mounting operations?  Or is it to
> > truncate strings reported via statfs to some arbitrary bound?  If it's the
> It is to not permit mount() operations whose mount point can't be
> recorded in the kernel because its name is too long.  There is a similar
> problem for the "from" name.  At least the following non-interactive
> operations now depend on the names being recorded properly: fsck (for
> hotroot stuff)  and `umount -A'. 

umount seems to be fairly broken anyway at this point due to apparently
bogus sanity checks.  The following are all now broken:

1) unmounting using a mountpoint from within a chroot when the mount was
   first done outside the chroot.  To reproduce:

   MDDEVICE=`mdconfig -a -t malloc -s 10240`
   disklabel -r -w $MDDEVICE auto
   newfs /dev/${MDDEVICE}c
   mkdir /tmp/chroot
   mkdir /tmp/chroot/bin
   mkdir /tmp/chroot/sbin
   cp /bin/{csh,sh,ls} /tmp/chroot/bin
   cp /sbin/{umount,mount*} /tmp/chroot/sbin
   mkdir /tmp/chroot/tmp
   mount ${MDDEVICE}c /tmp/chroot/tmp
   chroot /tmp/chroot
   umount /tmp

2) unmounting a mountpoint constructed within a chroot is broken from
   outside the chroot.  To reproduce this, do much the same as above, only
   also mount devfs on /dev in the mount, and mount the md device on /tmp
   after chroot'ing.  Then exit the chroot, and attempt to unmount

3) If you rename a directory on the path to the mountpoint, it's not
   possible to unmount the directory by name:

   curry# mount /dev/md0c /tmp/chroot/tmp
   curry# mv /tmp/chroot /tmp/chroot1
   curry# umount /tmp/chroot1/tmp
   umount: /tmp/chroot1/tmp: not currently mounted

With regards to umount -A.  It sounds like that is either incorrectly
implemented, or poorly implemented.  In fact, I'm not sure there is a
"right" way to implement "unmount -A" without kernel assistance, since the
namespaces revealed by statfs are relative to the process that did the
mounting, not the one doing the unmounting, and they are cached paths that
were in exitence at the time of the mount, and may no longer exist.  With
both UFS and non-UFS file systems, the mount-time path cannot be assumed
to be the same as the path at unmount time.  umount -A should probably be
a special-form request to the kernel that asks the kernel to unmount
everything.  Given that the process root may not be equal to the system
root (and the system root is a somewhat bugos concept anyway), the entire
concept of umount -A seems pretty messy, and something to avoid.  Also,
given that union mounting and covering of existing mountpoints are both
possible, the idea that a userland process can determine the unmounting
order without apriori knowledge seems flawed.

It should also be noted that the only reason that umount works even
remotely correctly right now is that mount calls realpath() before handing
the mountpoint argument to the kernel.  However, the mount() syscall does
not (and really cannot, due to the nature of VFS) determine the absolute
pathname safely, and so it treats the mountpoint cached pathanme for
statfs purely as a string (hence the truncation behavior).

It seems to me that the real fixes here are:

  Make structures and code currently using MNAMELEN use the normal
  path constant instead.

  Remove all use of statfs in umount, at least in as much as any
  information involving paths is derived from the path information
  returned, as those paths may be unrelated to the mount.  For example,
  imagine the rename scenario above where another file system is now
  mounted on /tmp/chroot/tmp instead.  When I ask for something to
  be unmounted by giving it a path, I really do mean that path, and
  not something else.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]      NAI Labs, Safeport Network Services

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to