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