On Fri, 31 Aug 2007, Jakob Oestergaard wrote:
>
> > The fact that he may *also* have broken insane setups is totally
> > irrelevant. Don't go off on some tangent that has nothing to do with the
> > regression in question!
>
> It does not have "nothing" to do with the regression.
>
> Some setups which worked more by accident than by design earlier on were broken
> by the fix. This could have been avoided, I agree, but the breakage was caused
> by the fix (or the breakage is the fix, however you prefer to look at it).
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.
> *part* of it wasn't a security hole.
>
> The other half very much was.
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.
> Sure, given that Trond (or whomever) has the time it takes to go and implement
> all of this, there's no need to screw anyone.
>
> Assuming he's on a schedule and this will have to wait, I agree with him that
> it makes the most sense to play it safe security/consistency-wise rather than
> functionality-wise.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
