On Tue, 30 May 2000, Alan Cox wrote:
> > Since there does not seem to be security issues in there, it's a
> > matter of policy. Policy belongs to userspace. So do the test in the
> > userspace mount, not in the kernel.
>
> You can't. There is an implicit race. What you can do is require a
> MNT_REMOUNT flag or similar so that the policy is set in user space still
Alan, if we are talking about that sort of races we are in for a lot of
fun with mount(8) and /etc/mtab. Not that it was that critical (personally
I'ld rather see /etc/mtab dead), but the same arguments re legacy programs
apply nicely.
Yes, MNT_NOT_IF_ROOT makes sense. However, I'ld rather postpone that one
until the decision on mount(2) interface (or the interface of whatever new
syscall(s) will be used). I mean, just look at mount(8) syntax:
We have -t <type> argument. Depending on the type we have different sets
of -o <option> arguments available. -t is mandatory, unless there is a
magical -o option - remount. If it's present -t _may_ be present, but is
ignored (in all honesty, wrong type should cause error). Set of -o options
contains some that are translated into flags; the rest is passed to
filesystem. The latter is fs-dependent and opaque both for mount(8) and
sys_mount(). To add more fun, we'll need some syntax for loopbacks and
unions, right? What with them - -t <fake_type>, -o <magic_option>? What on
the kernel side - should they be turned into flags by caller?
It's a bloody mess and if you add NFS and friends into the picture you'll
see even nastier stuff. If we need to change mount(8) (and looks like we
do) we might as well think about more regular interface of (new) syscall
and at least try to prevent further shitting of mount(8) syntax. If you
want to discuss that stuff - you are welcome, I'm pretty interested in
ideas that might help here. Comments?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed May 31 2000 - 21:00:25 EST