> Today I am wondering why we need to [...] canonicalise the block > device name for mount.
> Currently I am seeing 4 reasonable choices... > 1) just omit the pathadj() of the block device name, and just use > whatever the user says to use, unchanged. I doubt anything would > really be affected by this, but it does make a difference if some > user were to use > /./dev/../dev/wd0e > or wd0e > where the latter is either a symlink to /dev/wd0e, or a copy of /dev/wd0e > or $PWD==/dev and it is simply a relative path. If using the single-argument form of mount, as tlaronde@ pointed out, it can affect the lookup in fstab. I'm not sure whether I think that's good, bad, both, neither.... It could also matter in that it would lead to a possibly-confusing mount-from string in the mount table. I'm not sure whether that would matter, either, but it's something that needs to be thought about. Also consider what happens if, say, a mount of /dev/foo is done in a chroot. The mount-on directory path is mapped between chroot and host, but I think the mount-from path is not, and /dev/foo in the chroot may not be the same as /dev/foo in the host. I'm not sure whether I think that needs fixing either. > 2) we could prohibit relative paths, or paths containing '.' or '..' > components - simply check the path and refuse the mount. We could. I don't see why we'd want to, though, especially since in the presence of symlinks .. is not equivalent to stripping off the preceding pathname component (that is, /foo/bar/.. may not be /foo). > 3) we could apply pathadj() (as it currently is) to the paths which > choice 2 would prohibit (which won't affect the rump using ATF tests, > which don't do that). And do what if pathadj fails? > 4) we could change the pathadj() of the block device name to instead > simply call realpath(3), use the result if that succeeds (which is > what happens now, and in the past), but simply use the user's arg if > it fails [...]. I'm not entirely sure, but at the moment I think I would probably go for (1), pending finding something it breaks. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
