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
/dev/chroot/tmp.
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
