tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Sanitizing (canonicalising) the block device name in mount_ffs ??
> 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 mouse%rodents-montreal.org@localhost
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Home |
Main Index |
Thread Index |
Old Index