Well, it's not a "fix" if it breaks other setups.
It's especially not a fix since the whole requirement that all the flags
be exactly the same is totally brain-dead in the first place. We *have*
that kind of mount already, and it has nothing to do with NFS: it's called
a "bind" mount.
So if you want an identical mount, with cache coherency and tying the two
mount-points together (requiring that they have the same mount flags),
then that has absolutely *nothing* to do with NFS. The VFS layer does that
for you.
No, the fix was simply wrong. It was done the wrong way, and it broke
things it shouldn't have broken.
Let's put it this way: if I create a patch that stops the system from
booting, I sure as hell fix a potential security hole, don't I?
Does that make my patch a "fix"?
No it does not.
I disagree. Either that thing gets fixed before 2.6.23, or the commit that
introduced the broken behaviour gets reverted.
We've had this policy of "regressions are fixed" for a long time, and
we're not suddenly changing it.
This is *not* a security hole. In order to make it a security hole, you
need to be root in the first place. So what you call a security hole is
really no different from root installing a bad SUID binary. It's simply
not the kernels place to then say "SUID binaries will not work, because
it's a potential security hole".
See?
So stop calling this a security hole. It's certainly a misfeature, but:
- it's a misfeature that people are used to, and has been around forever.
- there are bound to be ways to fix it that don't break existing users.
- the requirement that all flags be the same for a mount to the same NFS
directory is *particularly* stupid, since there are better ways to do
that than go through NFS!
so I really don't see why people excuse the new behaviour.
Linus
-
