kern/61810: mounts done within a chroot show up wrong and can't be unmounted from outside.

[Clifton Royston]

>Number:         61810
>Category:       kern
>Synopsis:       mounts done within a chroot show up wrong and can't be unmounted from outside.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 23 17:10:15 PST 2004
>Closed-Date:
>Last-Modified:
>Originator:     Clifton Royston
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
Tiki Technologies
>Environment:
System: FreeBSD bass.tikitechnologies.com 4.8-RELEASE FreeBSD 4.8-RELEASE #3: Tue Jul 8 09:29:40 HST 2003 baron at bass.lava.net:/usr/obj/usr/src/sys/LAVA i386

	FreeBSD 4.8 (RELENG_4_8) 

>Description:

  Mounting any special device from within a chroot results in mount (even
outside the chroot) displaying the mount point relative to the chroot, which
is not valid in any other context.  Attempting to unmount the file outside
the chroot either by the associated device, the displayed mount-point
directory, or the full path to the mount point fails.
 
  The result is a mount that can only be removed by going back into the
chroot environment from which it was mounted and unmounting it there.  (If
the chroot directory had subsequently been removed, you would probably have
to reboot the server without unmounting it.)

  This may sound unlikely, but I found it by stumbling across it.  After a
"make release" failed due to an oversized floppy image I ended up with one
of these non-unmountable mounts of /dev/vnn0c on "/mnt".  The first time it
happened I ended up having to reboot the server to clear it.  The second
time I tracked it down more closely, resulting in this report.

>How-To-Repeat:

  The easiest way to replicate this is on a system set up to make releases
which is how I stumbled across it.

  Otherwise, create a chroot directory (as /var/release in the example
below), populate it with an empty /mnt, a basic /etc, /dev and with
appropriate binaries referenced below such as /sbin/mount* and
sbin/umount, and then execute:

bass:/home/cliftonr# chroot /var/release mount /dev/fd0 /mnt
bass:/home/cliftonr# mount
/dev/da0s1a on / (ufs, local)
/dev/da0s1d on /altroot (ufs, local)
/dev/da0s1e on /data (ufs, local, soft-updates)
/dev/da0s1f on /home (ufs, local, soft-updates)
/dev/da0s1h on /usr (ufs, local, soft-updates)
/dev/da0s1g on /var (ufs, local, soft-updates)
procfs on /proc (procfs, local)
/dev/fd0 on /mnt (ufs, local)
bass:/home/cliftonr# umount /dev/fd0
umount: unmount of /mnt failed: Invalid argument
bass:/home/cliftonr# umount /mnt
umount: unmount of /mnt failed: Invalid argument
bass:/home/cliftonr# umount /var/release/mnt
umount: /var/release/mnt: not currently mounted
bass:/home/cliftonr# chroot /var/release umount /dev/fd0
bass:/home/cliftonr# mount
/dev/da0s1a on / (ufs, local)
/dev/da0s1d on /altroot (ufs, local)
/dev/da0s1e on /data (ufs, local, soft-updates)
/dev/da0s1f on /home (ufs, local, soft-updates)
/dev/da0s1h on /usr (ufs, local, soft-updates)
/dev/da0s1g on /var (ufs, local, soft-updates)
procfs on /proc (procfs, local)

>Fix:

	When the situation arises, if the chroot and mount point still exist
chrooting back into them to execute the umount works, as shown above. 
However, it seems to me to be a bug that the initial mount stores the mount
point information - something which has visibility and pertains to the whole
system, outside the chroot - in a form which ends up being invalid outside
the chroot, both for display and for use with umount.

  No real clue how to fix it - maybe have mount also store the device ID and
inode/vnode along with the path when the mount succeeds, and be able to
rederive a full path from that?

  -- Clifton

>Release-Note:
>Audit-Trail:
>Unformatted: