This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
Thanks,
Miklos
----
From: Miklos Szeredi <[email protected]>
I added a nasty local variable shadowing bug to fuse in 2.6.24, with
the result, that the 'default_permissions' mount option is basically
ignored.
How did this happen?
- old err declaration in inner scope
- new err getting declared in outer scope
- 'return err' from inner scope getting removed
- old declaration not being noticed
-Wshadow would have saved us, but it doesn't seem practical for
the kernel :(
More testing would have also saved us :((
Signed-off-by: Miklos Szeredi <[email protected]>
---
Index: linux/fs/fuse/dir.c
===================================================================
--- linux.orig/fs/fuse/dir.c 2008-02-15 10:46:06.000000000 +0100
+++ linux/fs/fuse/dir.c 2008-02-15 11:05:46.000000000 +0100
@@ -906,7 +906,7 @@ static int fuse_permission(struct inode
}
if (fc->flags & FUSE_DEFAULT_PERMISSIONS) {
- int err = generic_permission(inode, mask, NULL);
+ err = generic_permission(inode, mask, NULL);
/* If permission is denied, try to refresh file
attributes. This is also needed, because the root
On Fri, 2008-02-15 at 11:23 +0100, Miklos Szeredi wrote:
> This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
>
> Thanks,
> Miklos
> ----
>
> From: Miklos Szeredi <[email protected]>
>
> I added a nasty local variable shadowing bug to fuse in 2.6.24, with
> the result, that the 'default_permissions' mount option is basically
> ignored.
>
> How did this happen?
>
> - old err declaration in inner scope
> - new err getting declared in outer scope
> - 'return err' from inner scope getting removed
> - old declaration not being noticed
>
> -Wshadow would have saved us, but it doesn't seem practical for
> the kernel :(
>
> More testing would have also saved us :((
sparse would have saved you too.
Harvey
On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
>
> Thanks,
> Miklos
> ----
>
> From: Miklos Szeredi <[email protected]>
>
> I added a nasty local variable shadowing bug to fuse in 2.6.24, with
> the result, that the 'default_permissions' mount option is basically
> ignored.
When this goes into Linus's tree, can you let us know along with the git
commit id?
thanks,
greg k-h
> On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> >
> > Thanks,
> > Miklos
> > ----
> >
> > From: Miklos Szeredi <[email protected]>
> >
> > I added a nasty local variable shadowing bug to fuse in 2.6.24, with
> > the result, that the 'default_permissions' mount option is basically
> > ignored.
>
> When this goes into Linus's tree, can you let us know along with the git
> commit id?
I'd really like to see this in 2.6.24.3. How much time is left?
Should I bypass Andrew and submit to Linus ASAP?
Thanks,
Miklos
On Sat, Feb 23, 2008 at 10:38:59AM +0100, Miklos Szeredi wrote:
> > On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> > >
> > > Thanks,
> > > Miklos
> > > ----
> > >
> > > From: Miklos Szeredi <[email protected]>
> > >
> > > I added a nasty local variable shadowing bug to fuse in 2.6.24, with
> > > the result, that the 'default_permissions' mount option is basically
> > > ignored.
> >
> > When this goes into Linus's tree, can you let us know along with the git
> > commit id?
>
> I'd really like to see this in 2.6.24.3. How much time is left?
> Should I bypass Andrew and submit to Linus ASAP?
There will be a .24.4 soon afterward (week or so), so don't feel like
you have to rush. Unless this is some kind of security issue?
thanks,
greg k-h
On Sat, 23 Feb 2008 11:08:59 -0800 Greg KH <[email protected]> wrote:
> On Sat, Feb 23, 2008 at 10:38:59AM +0100, Miklos Szeredi wrote:
> > > On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > > > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> > > >
> > > > Thanks,
> > > > Miklos
> > > > ----
> > > >
> > > > From: Miklos Szeredi <[email protected]>
> > > >
> > > > I added a nasty local variable shadowing bug to fuse in 2.6.24, with
> > > > the result, that the 'default_permissions' mount option is basically
> > > > ignored.
> > >
> > > When this goes into Linus's tree, can you let us know along with the git
> > > commit id?
> >
> > I'd really like to see this in 2.6.24.3. How much time is left?
> > Should I bypass Andrew and submit to Linus ASAP?
>
> There will be a .24.4 soon afterward (week or so), so don't feel like
> you have to rush. Unless this is some kind of security issue?
>
I'll be sending a bunch of fixes to Linus this weekend, including this patch.
> > On Sat, Feb 23, 2008 at 10:38:59AM +0100, Miklos Szeredi wrote:
> > > > On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > > > > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> > > > >
> > > > > Thanks,
> > > > > Miklos
> > > > > ----
> > > > >
> > > > > From: Miklos Szeredi <[email protected]>
> > > > >
> > > > > I added a nasty local variable shadowing bug to fuse in 2.6.24, with
> > > > > the result, that the 'default_permissions' mount option is basically
> > > > > ignored.
> > > >
> > > > When this goes into Linus's tree, can you let us know along with the git
> > > > commit id?
> > >
> > > I'd really like to see this in 2.6.24.3. How much time is left?
> > > Should I bypass Andrew and submit to Linus ASAP?
> >
> > There will be a .24.4 soon afterward (week or so), so don't feel like
> > you have to rush. Unless this is some kind of security issue?
> >
>
> I'll be sending a bunch of fixes to Linus this weekend, including this patch.
Thanks.
Yes, this could have security implications, so the earlier, the better.
Miklos
Hi Greg!
> On Fri, Feb 15, 2008 at 11:23:47AM +0100, Miklos Szeredi wrote:
> > This is for 2.6.25 and 2.6.24.y, but NOT for 2.6.23.y.
> >
> > Thanks,
> > Miklos
> > ----
> >
> > From: Miklos Szeredi <[email protected]>
> >
> > I added a nasty local variable shadowing bug to fuse in 2.6.24, with
> > the result, that the 'default_permissions' mount option is basically
> > ignored.
>
> When this goes into Linus's tree, can you let us know along with the git
> commit id?
It's now in Linus tree:
commit 1a823ac9ff09cbdf39201df37b7ede1f9395de83
Thanks,
Miklos