Hello everyone, Btrfs v0.14 is now available for download. Please note the disk format has changed, and it is not compatible with older versions of Btrfs. For downloads and documention, please see the Btrfs project page: http://btrfs.wiki.kernel.org The oss.oracle.com Btrfs project page will soon start redirecting here. v0.14 has a few performance fixes and closes some races that could have allowed corrupted metadata in v0.13. The major new feature is the ability to manage multiple devices under a single Btrfs mount. Raid0, raid1 and raid10 are supported. Even for single device filesystems, metadata is now duplicated by default. Checksums are verified after reads finish and duplicate copies are used if the checksums don''t match. Multi-device design details can be found here: http://btrfs.wiki.kernel.org/index.php/Multiple_Device_Support And sample usage to create and add volumes can be found here: http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices I''m putting up some benchmarks of the new multi-device code as the runs finish: http://btrfs.wiki.kernel.org/index.php/Multi-device_Benchmarks Next up on the Btrfs todo list is finishing off the device removal and IO error handling code. After that I''ll add more fine grained locking to the btrees. Thanks to everyone who has helped contribute to and test this release. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 29 April 2008, Chris Mason wrote:> Hello everyone, > > Btrfs v0.14 is now available for download. Please note the disk format has > changed, and it is not compatible with older versions of Btrfs. > > For downloads and documention, please see the Btrfs project page: > > http://btrfs.wiki.kernel.org >Hello everyone, I''ve rolled up some fixes for older kernels and fixed an uninitialized variables in btrfs-progs that could cause an oops on mount. I''ll wait a few days to see if other bug reports come in and cut a 0.15 with any other critical fixes. Until then, you can find download information on the important fixes so far: http://btrfs.wiki.kernel.org/index.php/Hot_Fixes -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, May 1, 2008 at 9:04 AM, Chris Mason <chris.mason@oracle.com> wrote:> On Tuesday 29 April 2008, Chris Mason wrote: > > Hello everyone, > > > > Btrfs v0.14 is now available for download. Please note the disk format has > > changed, and it is not compatible with older versions of Btrfs. > > > > For downloads and documention, please see the Btrfs project page: > > > > http://btrfs.wiki.kernel.org > > > > Hello everyone, > > I''ve rolled up some fixes for older kernels and fixed an uninitialized > variables in btrfs-progs that could cause an oops on mount. I''ll wait a few > days to see if other bug reports come in and cut a 0.15 with any other > critical fixes.Well it oopses on writes everytime in Ubuntu 8.04 (Hardy). I''d planned on digging into it more before spending a bug report, but will send it tonight after getting to the affected machine. With 1 volume on 1 disk, 2 volumes raid1 on 2 disks, or with 2 volumes raid0 on 2 disks. something like: echo omg > /mnt/btrfs/file Would segfault, exit the current shell, and leave a nice stack trace in the kernel''s ring buffer. The file gets created as 0 bytes. Unlinking the file works fine via rm, but any sort of write fails. Tried and reproduced the bug with stdout redirection, cp, and dd to a btrfs v0.14 volume. Will send the report later today.> > Until then, you can find download information on the important fixes so far: > > http://btrfs.wiki.kernel.org/index.php/Hot_Fixes > > > > -chris-- Jeff Schroeder Don''t drink and derive, alcohol and analysis don''t mix. http://www.digitalprognosis.com
On Thursday 01 May 2008, Jeff Schroeder wrote:> On Thu, May 1, 2008 at 9:04 AM, Chris Mason <chris.mason@oracle.com> wrote: > > On Tuesday 29 April 2008, Chris Mason wrote: > > > Hello everyone, > > > > > > Btrfs v0.14 is now available for download. Please note the disk > > > format has changed, and it is not compatible with older versions of > > > Btrfs. > > > > > > For downloads and documention, please see the Btrfs project page: > > > > > > http://btrfs.wiki.kernel.org > > > > Hello everyone, > > > > I''ve rolled up some fixes for older kernels and fixed an uninitialized > > variables in btrfs-progs that could cause an oops on mount. I''ll wait a > > few days to see if other bug reports come in and cut a 0.15 with any > > other critical fixes. > > Well it oopses on writes everytime in Ubuntu 8.04 (Hardy). I''d planned > on digging into > it more before spending a bug report, but will send it tonight after > getting to the affected > machine.This is because ubuntu kernels ship with apparmor, you''ll need this patch: If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff Mahoney has a similar patch for SUSE that I''ve been meaning to merge, but I wanted to lookup some way to check for ubuntu as well. -chris diff -r e7da2489b19b file.c --- a/file.c Wed Apr 30 13:59:35 2008 -0400 +++ b/file.c Thu May 01 12:25:11 2008 -0400 @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f goto out_nolock; if (count == 0) goto out_nolock; - err = remove_suid(fdentry(file)); + err = remove_suid(&file->f_path); if (err) goto out_nolock; file_update_time(file); -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
adding the ubuntu kernel team. BenC or TimG, do you have any suggestions for Chris? On Thu, May 1, 2008 at 9:26 AM, Chris Mason <chris.mason@oracle.com> wrote:> On Thursday 01 May 2008, Jeff Schroeder wrote: > > On Thu, May 1, 2008 at 9:04 AM, Chris Mason <chris.mason@oracle.com> wrote: > > > On Tuesday 29 April 2008, Chris Mason wrote: > > > > Hello everyone, > > > > > > > > Btrfs v0.14 is now available for download. Please note the disk > > > > format has changed, and it is not compatible with older versions of > > > > Btrfs. > > > > > > > > For downloads and documention, please see the Btrfs project page: > > > > > > > > http://btrfs.wiki.kernel.org > > > > > > Hello everyone, > > > > > > I''ve rolled up some fixes for older kernels and fixed an uninitialized > > > variables in btrfs-progs that could cause an oops on mount. I''ll wait a > > > few days to see if other bug reports come in and cut a 0.15 with any > > > other critical fixes. > > > > Well it oopses on writes everytime in Ubuntu 8.04 (Hardy). I''d planned > > on digging into > > it more before spending a bug report, but will send it tonight after > > getting to the affected > > machine. > > This is because ubuntu kernels ship with apparmor, you''ll need this patch: > > If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff Mahoney > has a similar patch for SUSE that I''ve been meaning to merge, but I wanted to > lookup some way to check for ubuntu as well. > > -chris > > diff -r e7da2489b19b file.c > --- a/file.c Wed Apr 30 13:59:35 2008 -0400 > +++ b/file.c Thu May 01 12:25:11 2008 -0400 > @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f > goto out_nolock; > if (count == 0) > goto out_nolock; > - err = remove_suid(fdentry(file)); > + err = remove_suid(&file->f_path); > if (err) > goto out_nolock; > file_update_time(file); >-- Jeff Schroeder Don''t drink and derive, alcohol and analysis don''t mix. http://www.digitalprognosis.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff Schroeder wrote:> adding the ubuntu kernel team. BenC or TimG, do you have any > suggestions for Chris? > > On Thu, May 1, 2008 at 9:26 AM, Chris Mason <chris.mason@oracle.com> wrote: >> On Thursday 01 May 2008, Jeff Schroeder wrote: >> > On Thu, May 1, 2008 at 9:04 AM, Chris Mason <chris.mason@oracle.com> wrote: >> > > On Tuesday 29 April 2008, Chris Mason wrote: >> > > > Hello everyone, >> > > > >> > > > Btrfs v0.14 is now available for download. Please note the disk >> > > > format has changed, and it is not compatible with older versions of >> > > > Btrfs. >> > > > >> > > > For downloads and documention, please see the Btrfs project page: >> > > > >> > > > http://btrfs.wiki.kernel.org >> > > >> > > Hello everyone, >> > > >> > > I''ve rolled up some fixes for older kernels and fixed an uninitialized >> > > variables in btrfs-progs that could cause an oops on mount. I''ll wait a >> > > few days to see if other bug reports come in and cut a 0.15 with any >> > > other critical fixes. >> > >> > Well it oopses on writes everytime in Ubuntu 8.04 (Hardy). I''d planned >> > on digging into >> > it more before spending a bug report, but will send it tonight after >> > getting to the affected >> > machine. >> >> This is because ubuntu kernels ship with apparmor, you''ll need this patch: >> >> If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff Mahoney >> has a similar patch for SUSE that I''ve been meaning to merge, but I wanted to >> lookup some way to check for ubuntu as well. >> >> -chris >> >> diff -r e7da2489b19b file.c >> --- a/file.c Wed Apr 30 13:59:35 2008 -0400 >> +++ b/file.c Thu May 01 12:25:11 2008 -0400 >> @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f >> goto out_nolock; >> if (count == 0) >> goto out_nolock; >> - err = remove_suid(fdentry(file)); >> + err = remove_suid(&file->f_path); >> if (err) >> goto out_nolock; >> file_update_time(file); >> > > >Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to work for Hardy. However the next development kernel (Intrepid) does not have the APPARMOR patches, so just knowing that its an UBUNTU kernel is not specific enough. rtg -- Tim Gardner tim.gardner@ubuntu.com
On Thursday 01 May 2008, Tim Gardner wrote: [ btrfs oops on ubuntu ]> >> This is because ubuntu kernels ship with apparmor, you''ll need this > >> patch: > >> > >> If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff > >> Mahoney has a similar patch for SUSE that I''ve been meaning to merge, > >> but I wanted to lookup some way to check for ubuntu as well. > >> > >> -chris > >> > >> diff -r e7da2489b19b file.c > >> --- a/file.c Wed Apr 30 13:59:35 2008 -0400 > >> +++ b/file.c Thu May 01 12:25:11 2008 -0400 > >> @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f > >> goto out_nolock; > >> if (count == 0) > >> goto out_nolock; > >> - err = remove_suid(fdentry(file)); > >> + err = remove_suid(&file->f_path); > >> if (err) > >> goto out_nolock; > >> file_update_time(file); > > Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to > work for Hardy. However the next development kernel (Intrepid) does not > have the APPARMOR patches, so just knowing that its an UBUNTU kernel is > not specific enough.I''ve been assuming the apparmor patches change remove_suid even when they are not enabled in the config. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Mason wrote:> On Thursday 01 May 2008, Tim Gardner wrote: > > [ btrfs oops on ubuntu ] > >>>> This is because ubuntu kernels ship with apparmor, you''ll need this >>>> patch: >>>> >>>> If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff >>>> Mahoney has a similar patch for SUSE that I''ve been meaning to merge, >>>> but I wanted to lookup some way to check for ubuntu as well. >>>> >>>> -chris >>>> >>>> diff -r e7da2489b19b file.c >>>> --- a/file.c Wed Apr 30 13:59:35 2008 -0400 >>>> +++ b/file.c Thu May 01 12:25:11 2008 -0400 >>>> @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f >>>> goto out_nolock; >>>> if (count == 0) >>>> goto out_nolock; >>>> - err = remove_suid(fdentry(file)); >>>> + err = remove_suid(&file->f_path); >>>> if (err) >>>> goto out_nolock; >>>> file_update_time(file); >> Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to >> work for Hardy. However the next development kernel (Intrepid) does not >> have the APPARMOR patches, so just knowing that its an UBUNTU kernel is >> not specific enough. > > I''ve been assuming the apparmor patches change remove_suid even when they are > not enabled in the config.Yeah, unless Ubuntu is doing some magic with the function arguments (which sounds like the fix is worse than the problem), this is true. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIGhmULPWxlyuTD7IRAgJcAJ4zYYcgQ2V0eT6Fv6LstlwpnK9bUwCgpdBD XHUzfiFBd+HQLt5Tw5vHH0A=KWIZ -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason wrote:> On Thursday 01 May 2008, Tim Gardner wrote: > > [ btrfs oops on ubuntu ] > >>>> This is because ubuntu kernels ship with apparmor, you''ll need this >>>> patch: >>>> >>>> If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff >>>> Mahoney has a similar patch for SUSE that I''ve been meaning to merge, >>>> but I wanted to lookup some way to check for ubuntu as well. >>>> >>>> -chris >>>> >>>> diff -r e7da2489b19b file.c >>>> --- a/file.c Wed Apr 30 13:59:35 2008 -0400 >>>> +++ b/file.c Thu May 01 12:25:11 2008 -0400 >>>> @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f >>>> goto out_nolock; >>>> if (count == 0) >>>> goto out_nolock; >>>> - err = remove_suid(fdentry(file)); >>>> + err = remove_suid(&file->f_path); >>>> if (err) >>>> goto out_nolock; >>>> file_update_time(file); >> Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to >> work for Hardy. However the next development kernel (Intrepid) does not >> have the APPARMOR patches, so just knowing that its an UBUNTU kernel is >> not specific enough. > > I''ve been assuming the apparmor patches change remove_suid even when they are > not enabled in the config. > > -chris >Lets get Kees involved. He developed the patch set for Hardy. I would hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to its normal state. rtg -- Tim Gardner tim.gardner@ubuntu.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi, On Thu, May 01, 2008 at 01:36:25PM -0600, Tim Gardner wrote:> Chris Mason wrote: > > On Thursday 01 May 2008, Tim Gardner wrote: > > > > [ btrfs oops on ubuntu ] > > > >>>> This is because ubuntu kernels ship with apparmor, you''ll need this > >>>> patch: > >>>> > >>>> If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff > >>>> Mahoney has a similar patch for SUSE that I''ve been meaning to merge, > >>>> but I wanted to lookup some way to check for ubuntu as well. > >>>> > >>>> -chris > >>>> > >>>> diff -r e7da2489b19b file.c > >>>> --- a/file.c Wed Apr 30 13:59:35 2008 -0400 > >>>> +++ b/file.c Thu May 01 12:25:11 2008 -0400 > >>>> @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f > >>>> goto out_nolock; > >>>> if (count == 0) > >>>> goto out_nolock; > >>>> - err = remove_suid(fdentry(file)); > >>>> + err = remove_suid(&file->f_path); > >>>> if (err) > >>>> goto out_nolock; > >>>> file_update_time(file); > >> Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to > >> work for Hardy. However the next development kernel (Intrepid) does not > >> have the APPARMOR patches, so just knowing that its an UBUNTU kernel is > >> not specific enough. > > > > I''ve been assuming the apparmor patches change remove_suid even when they are > > not enabled in the config. > > > > -chris > > > > Lets get Kees involved. He developed the patch set for Hardy. I would > hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to > its normal state.I can''t claim to have developed the patches, only helping coordinate their merging into Ubuntu. John Johansen is the real person we should check with -- he did all the heavy lifting -- now added to discussion. (Hi John!) -Kees -- Kees Cook Ubuntu Security Team -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Gardner wrote:> Chris Mason wrote: >> On Thursday 01 May 2008, Tim Gardner wrote: >> >> [ btrfs oops on ubuntu ] >> >>>>> This is because ubuntu kernels ship with apparmor, you''ll need this >>>>> patch: >>>>> >>>>> If there is a #ifdef IM_A_UBUNTU_KERNEL I can use, I''ll do it. Jeff >>>>> Mahoney has a similar patch for SUSE that I''ve been meaning to merge, >>>>> but I wanted to lookup some way to check for ubuntu as well. >>>>> >>>>> -chris >>>>> >>>>> diff -r e7da2489b19b file.c >>>>> --- a/file.c Wed Apr 30 13:59:35 2008 -0400 >>>>> +++ b/file.c Thu May 01 12:25:11 2008 -0400 >>>>> @@ -852,7 +852,7 @@ static ssize_t btrfs_file_write(struct f >>>>> goto out_nolock; >>>>> if (count == 0) >>>>> goto out_nolock; >>>>> - err = remove_suid(fdentry(file)); >>>>> + err = remove_suid(&file->f_path); >>>>> if (err) >>>>> goto out_nolock; >>>>> file_update_time(file); >>> Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to >>> work for Hardy. However the next development kernel (Intrepid) does not >>> have the APPARMOR patches, so just knowing that its an UBUNTU kernel is >>> not specific enough. >> I''ve been assuming the apparmor patches change remove_suid even when they are >> not enabled in the config. >> >> -chris >> > > Lets get Kees involved. He developed the patch set for Hardy. I would > hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to > its normal state.remove_suid() isn''t the only change AppArmor makes to the VFS interface. It''s pretty invasive and requires that dentries are passed with a companion vfsmount in most cases. Putting #ifdefs around all that code would make the problem worse, not better. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFIGiOrLPWxlyuTD7IRAh3jAKCFCrBa30G5WDwmJHI+Yb4fNAfu2QCfTUmq Q6Sf0MVug2X0ywRcSrGi4eY=QwF9 -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 2008-05-01 22:10, Jeff Mahoney wrote:>>>> Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to >>>> work for Hardy. However the next development kernel (Intrepid) does not >>>> have the APPARMOR patches, so just knowing that its an UBUNTU kernel is >>>> not specific enough. >>> >>> I''ve been assuming the apparmor patches change remove_suid even when they are >>> not enabled in the config. >> >> Lets get Kees involved. He developed the patch set for Hardy. I would >> hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to >> its normal state. > >remove_suid() isn''t the only change AppArmor makes to the VFS interface. >It''s pretty invasive and requires that dentries are passed with a >companion vfsmount in most cases. Putting #ifdefs around all that code >would make the problem worse, not better.An alternative approach, and IMHO better suited, is to: make -C ${kdir} all I_HAZ_AN_APPARMOR=1 with this Makefile ifneq (${I_HAZ_AN_APPARMOR},) EXTRA_CFLAGS += -DHAZ_APPARMOR endif This works very well for kmp-rpms, which are tied to a specific distro, sometimes kernel, anyway. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 02 May 2008, Jan Engelhardt wrote:> On Thursday 2008-05-01 22:10, Jeff Mahoney wrote: > >>>> Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to > >>>> work for Hardy. However the next development kernel (Intrepid) does > >>>> not have the APPARMOR patches, so just knowing that its an UBUNTU > >>>> kernel is not specific enough. > >>> > >>> I''ve been assuming the apparmor patches change remove_suid even when > >>> they are not enabled in the config. > >> > >> Lets get Kees involved. He developed the patch set for Hardy. I would > >> hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to > >> its normal state. > > > >remove_suid() isn''t the only change AppArmor makes to the VFS interface. > >It''s pretty invasive and requires that dentries are passed with a > >companion vfsmount in most cases. Putting #ifdefs around all that code > >would make the problem worse, not better. > > An alternative approach, and IMHO better suited, is to: > > make -C ${kdir} all I_HAZ_AN_APPARMOR=1This is better than the current situation (oops without any clues), but I''d prefer that people not have to know what apparmor is or if they have it. (This isn''t a knock on apparmor, I''d just rather take care of it automagically). -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 2008-05-02 14:52, Chris Mason wrote:>> >> An alternative approach, and IMHO better suited, is to: >> >> make -C ${kdir} all I_HAZ_AN_APPARMOR=1 > >This is better than the current situation (oops without any clues), but I''d >prefer that people not have to know what apparmor is or if they have it.I guess iff people have a clue just what btrfs is and what it is good for and why one would need it, I guess they also know of Apparmor. If not, well, I hope you mentioned it in the INSTALL file! Documentation on the most important things is always a good thing.>(This isn''t a knock on apparmor, I''d just rather take care of it >automagically).Well you could go down the conftest.sh route, but I dislike that approach because such a Makefile system tries to be smarter than me; and that often breaks because developers made a mess out of the remaining Makefile and before long, it broke on odd, but "standards-conforming", O= builds. (Fun stories with nvidia.) -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 2008-05-02 14:52, Chris Mason wrote:>> >> An alternative approach, and IMHO better suited, is to: >> >> make -C ${kdir} all I_HAZ_AN_APPARMOR=1^ M=$PWD>This is better than the current situation (oops without any clues),If it oopses, then you probably also get a compile-time warning on that remove_suid line. And in that case, you can catch it with at least a compile-time typecheck so as to not make the user head straight into an oops, is not it? -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 2, 2008 at 5:52 AM, Chris Mason <chris.mason@oracle.com> wrote:> On Friday 02 May 2008, Jan Engelhardt wrote: > > On Thursday 2008-05-01 22:10, Jeff Mahoney wrote: > > >>>> Couldn''t you #ifdef based on CONFIG_SECURITY_APPARMOR ? This ought to > > >>>> work for Hardy. However the next development kernel (Intrepid) does > > >>>> not have the APPARMOR patches, so just knowing that its an UBUNTU > > >>>> kernel is not specific enough. > > >>> > > >>> I''ve been assuming the apparmor patches change remove_suid even when > > >>> they are not enabled in the config. > > >> > > >> Lets get Kees involved. He developed the patch set for Hardy. I would > > >> hope that if CONFIG_SECURITY_APPARMOR=n then the source would default to > > >> its normal state. > > > > > >remove_suid() isn''t the only change AppArmor makes to the VFS interface. > > >It''s pretty invasive and requires that dentries are passed with a > > >companion vfsmount in most cases. Putting #ifdefs around all that code > > >would make the problem worse, not better. > > > > An alternative approach, and IMHO better suited, is to: > > > > make -C ${kdir} all I_HAZ_AN_APPARMOR=1 > > This is better than the current situation (oops without any clues), but I''d > prefer that people not have to know what apparmor is or if they have it. > (This isn''t a knock on apparmor, I''d just rather take care of it > automagically).Chris, Make is not my forte, but here is a working test to see if apparmor exists in Ubuntu 8.04. Maybe have make apply a patch to the btrfs source if this test succeeds? Does this work in SUSE? http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_test_for_btrfs.patch The symlink from /lib/modules/`uname -r`/build -> /path/to/kernel/headers/ doesn''t exist on CentOS 5. Even though it is a hack, is this or something like it usable? Or is this the completely wrong direction? -- Jeff Schroeder Don''t drink and derive, alcohol and analysis don''t mix. http://www.digitalprognosis.com
On Friday 2008-05-02 16:15, Jeff Schroeder wrote:> >Make is not my forte, but here is a working test to see if apparmor >exists in Ubuntu 8.04. >Maybe have make apply a patch to the btrfs source if this test >succeeds? Does this work in SUSE? > >http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_test_for_btrfs.patchWoah, you rely on autoconf.h. Uh no thanks, let the build system handle it. # -*- Makefile -*- btrfs-objs := ... obj-m += btrfs.o and-so-on.o ifneq (${CONFIG_SECURITY_APPARMOR},) EXTRA_CFLAGS += -DI_HAZ_AN_APPARMOR endif all: ${MAKE} -C ${kdir} M=$PWD all; Best of all, you can override that from the command line too... make CONFIG_SECURITY_APPARMOR=y (and if you don''t, it takes its value from the appropriate .config, all without you having to care about autoconf.h) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 02 May 2008, Jeff Schroeder wrote: [ Btrfs oops with apparmor patched in ]> Make is not my forte, but here is a working test to see if apparmor > exists in Ubuntu 8.04. > Maybe have make apply a patch to the btrfs source if this test > succeeds? Does this work in SUSE? > > http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_test >_for_btrfs.patch >Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn''t enough to tell if the kernel has the patch. Lets go back to Jeff''s suse patch: /* * Even if AppArmor isn''t enabled, it still has different prototypes. * Add more distro/version pairs here to declare which has AppArmor applied. */ #if defined(CONFIG_SUSE_KERNEL) # if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22) # define REMOVE_SUID_PATH 1 # endif #endif Could someone from Ubuntu please suggest a replacement for CONFIG_SUSE_KERNEL and KERNEL_VERSION(2,6,22) that would correspond with ubuntu kernels shipped with apparmor? We don''t need some define from the apparmor patch, just a global flag that says it comes from ubuntu is enough. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 02, 2008 at 10:34:07AM -0400, Chris Mason wrote:> Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn''t enough to tell if > the kernel has the patch. Lets go back to Jeff''s suse patch:Do we really need to support kernels compiled with the apparmour patch applied but not enabled? That would be a custom kernel build, and I get the impression that people Just Don''t Do That -- if they want a newer kernel, they fetch one from kernel.org. Maybe I''m wrong though. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you''re interested in selling us this operating system, but compare it to ours. We can''t possibly take such a retrograde step." -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 02 May 2008, Matthew Wilcox wrote:> On Fri, May 02, 2008 at 10:34:07AM -0400, Chris Mason wrote: > > Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn''t enough to tell > > if the kernel has the patch. Lets go back to Jeff''s suse patch: > > Do we really need to support kernels compiled with the apparmour patch > applied but not enabled? That would be a custom kernel build, and I get > the impression that people Just Don''t Do That -- if they want a newer > kernel, they fetch one from kernel.org. Maybe I''m wrong though.Yeah, if there''s no better test I''ll just use the one for the apparmor config (and stop spamming l-k with this btrfs specific stuff). -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 2008-05-02 16:38, Matthew Wilcox wrote:>On Fri, May 02, 2008 at 10:34:07AM -0400, Chris Mason wrote: >> Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn''t enough to tell if >> the kernel has the patch. Lets go back to Jeff''s suse patch: > >Do we really need to support kernels compiled with the apparmour patch >applied but not enabled? That would be a custom kernel build, and I get >the impression that people Just Don''t Do That -- if they want a newer >kernel, they fetch one from kernel.org. Maybe I''m wrong though.I think so too. Corollary: if there is a distro that has apparmor patched into its kernel, then there is [hopefully] a suitable rpm nearby. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Chris Mason wrote:> On Friday 02 May 2008, Jeff Schroeder wrote: > > [ Btrfs oops with apparmor patched in ] > >> Make is not my forte, but here is a working test to see if apparmor >> exists in Ubuntu 8.04. >> Maybe have make apply a patch to the btrfs source if this test >> succeeds? Does this work in SUSE? >> >> http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_test >> _for_btrfs.patch >> > > Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn''t enough to tell if > the kernel has the patch. Lets go back to Jeff''s suse patch: > > /* > * Even if AppArmor isn''t enabled, it still has different prototypes. > * Add more distro/version pairs here to declare which has AppArmor applied. > */ > #if defined(CONFIG_SUSE_KERNEL) > # if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22) > # define REMOVE_SUID_PATH 1 > # endif > #endif > > Could someone from Ubuntu please suggest a replacement for CONFIG_SUSE_KERNEL > and KERNEL_VERSION(2,6,22) that would correspond with ubuntu kernels shipped > with apparmor? We don''t need some define from the apparmor patch, just a > global flag that says it comes from ubuntu is enough. > > -chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >To the best of my knowledge, the AppArmor patches are arch and flavour independent. If CONFIG_SECURITY_APPARMOR exists, then the AA code is compiled. This is certainly the case for Hardy. Neither Kees or myself are aware of any reason why it won''t also hold true for Intrepid. rtg -- Tim Gardner timg@tpi.com www.tpi.com OR 503-601-0234 x102 MT 406-443-5357
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Gardner wrote:> Chris Mason wrote: >> On Friday 02 May 2008, Jeff Schroeder wrote: >> >> [ Btrfs oops with apparmor patched in ] >> >>> Make is not my forte, but here is a working test to see if apparmor >>> exists in Ubuntu 8.04. >>> Maybe have make apply a patch to the btrfs source if this test >>> succeeds? Does this work in SUSE? >>> >>> http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_test >>> _for_btrfs.patch >>> >> Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn''t enough to tell if >> the kernel has the patch. Lets go back to Jeff''s suse patch: >> >> /* >> * Even if AppArmor isn''t enabled, it still has different prototypes. >> * Add more distro/version pairs here to declare which has AppArmor applied. >> */ >> #if defined(CONFIG_SUSE_KERNEL) >> # if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,22) >> # define REMOVE_SUID_PATH 1 >> # endif >> #endif >> >> Could someone from Ubuntu please suggest a replacement for CONFIG_SUSE_KERNEL >> and KERNEL_VERSION(2,6,22) that would correspond with ubuntu kernels shipped >> with apparmor? We don''t need some define from the apparmor patch, just a >> global flag that says it comes from ubuntu is enough. >> >> -chris >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> Please read the FAQ at http://www.tux.org/lkml/ >> > > To the best of my knowledge, the AppArmor patches are arch and flavour > independent. If CONFIG_SECURITY_APPARMOR exists, then the AA code is > compiled. This is certainly the case for Hardy. Neither Kees or myself > are aware of any reason why it won''t also hold true for Intrepid.Grumble. The issue isn''t whether AA is enabled, it''s whether it''s present in the source. Patching the source with AA modifies a bunch of core VFS function prototypes. CONFIG_SECURITY_APPARMOR won''t exist if AA isn''t enabled, but the prototypes will have changed anyway. The SUSE kernel doesn''t export information about the presence of particular features, but it does identify itself as a SUSE kernel so that the pair of CONFIG_SUSE_KERNEL and the version number will identify a release. For our enterprise kernels, where the version number won''t change over the lifetime of the release, we identify release version and service pack levels as well. I took a look at config-2.6.24-16-generic from 8.04 and didn''t see anything comparable. At any rate, it''s probably enough to ignore that corner case and assume that any kernel with AA patched in will have it enabled. Anyone building a distro kernel themselves to disable AA will probably also have the knowledge to work around it in the btrfs source. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkgbQJoACgkQLPWxlyuTD7KhZACfZeZMBNx6x/avk5a2AED1g4rV deEAnjgTp18gxVn4d7USmdfSXOeweG52 =/yZN -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 2008-05-02 18:26, Jeff Mahoney wrote:>> >> To the best of my knowledge, the AppArmor patches are arch and flavour >> independent. If CONFIG_SECURITY_APPARMOR exists, then the AA code is >> compiled. This is certainly the case for Hardy. Neither Kees or myself >> are aware of any reason why it won''t also hold true for Intrepid. > >Grumble. The issue isn''t whether AA is enabled, it''s whether it''s >present in the source. Patching the source with AA modifies a bunch of >core VFS function prototypes. CONFIG_SECURITY_APPARMOR won''t exist if AA >isn''t enabled, but the prototypes will have changed anyway.So... add an invisible CONFIG_HAVE_APPARMOR, much like CONFIG_X86_HAVE_CMPXCHG (or whatever it''s called), and test for that. As long as you are not in the mainline kernel, every hack is forgiven. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jan Engelhardt wrote:> On Friday 2008-05-02 18:26, Jeff Mahoney wrote: >>> To the best of my knowledge, the AppArmor patches are arch and flavour >>> independent. If CONFIG_SECURITY_APPARMOR exists, then the AA code is >>> compiled. This is certainly the case for Hardy. Neither Kees or myself >>> are aware of any reason why it won''t also hold true for Intrepid. >> Grumble. The issue isn''t whether AA is enabled, it''s whether it''s >> present in the source. Patching the source with AA modifies a bunch of >> core VFS function prototypes. CONFIG_SECURITY_APPARMOR won''t exist if AA >> isn''t enabled, but the prototypes will have changed anyway. > > So... add an invisible CONFIG_HAVE_APPARMOR, much like > CONFIG_X86_HAVE_CMPXCHG (or whatever it''s called), and test for that. > As long as you are not in the mainline kernel, every hack is > forgiven.That''ll work moving forward, but btrfs also supports older releases. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkgbVv0ACgkQLPWxlyuTD7JLrACfUKFXwh/nYuwDw7oT3lFLs/E7 cNQAn2LQKNJkIc/SDQJJ2ykuvYAg++D8 =1Ami -----END PGP SIGNATURE----- -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, May 2, 2008 at 11:01 AM, Jeff Mahoney <jeffm@suse.com> wrote:> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Jan Engelhardt wrote: > > On Friday 2008-05-02 18:26, Jeff Mahoney wrote: > >>> To the best of my knowledge, the AppArmor patches are arch and flavour > >>> independent. If CONFIG_SECURITY_APPARMOR exists, then the AA code is > >>> compiled. This is certainly the case for Hardy. Neither Kees or myself > >>> are aware of any reason why it won''t also hold true for Intrepid. > >> Grumble. The issue isn''t whether AA is enabled, it''s whether it''s > >> present in the source. Patching the source with AA modifies a bunch of > >> core VFS function prototypes. CONFIG_SECURITY_APPARMOR won''t exist if AA > >> isn''t enabled, but the prototypes will have changed anyway. > > > > So... add an invisible CONFIG_HAVE_APPARMOR, much like > > CONFIG_X86_HAVE_CMPXCHG (or whatever it''s called), and test for that. > > As long as you are not in the mainline kernel, every hack is > > forgiven. > > That''ll work moving forward, but btrfs also supports older releases. > > > - -JeffSo how about this for older releases? It should work on Ubuntu 7.10 or 8.10 installs with apparmor enabled by default: #if defined(CONFIG_VERSION_SIGNATURE) # if (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,24)) || (LINUX_VERSION_CODE = KERNEL_VERSION(2,6,20)) # define REMOVE_SUID_PATH 1 # endif #endif Maybe add a blurb in the install doc about this for users trying to build ubuntu kernels with no apparmor (probably a rarity). CONFIG_VERSION_SIGNATURE can be likened to CONFIG_SUSE -- Jeff Schroeder Don''t drink and derive, alcohol and analysis don''t mix. http://www.digitalprognosis.com -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday 02 May 2008, Tim Gardner wrote:> Chris Mason wrote: > > On Friday 02 May 2008, Jeff Schroeder wrote: > > > > [ Btrfs oops with apparmor patched in ] > > > >> Make is not my forte, but here is a working test to see if apparmor > >> exists in Ubuntu 8.04. > >> Maybe have make apply a patch to the btrfs source if this test > >> succeeds? Does this work in SUSE? > >> > >> http://www.digitalprognosis.com/opensource/patches/btrfs/lame_apparmor_t > >>est _for_btrfs.patch > > > > Thanks, but this uses CONFIG_SECURITY_APPARMOR which isn''t enough to tell > > if the kernel has the patch. Lets go back to Jeff''s suse patch: > >I ended up using the CONFIG_SECURITY_APPARMOR test because the other test suggested here sounded like something that might eventually not be very ubuntu specific (instead of the nice a plain CONFIG_SUSE_KERNEL). Thanks to everyone for the hints, if someone could please test: http://btrfs.wiki.kernel.org/index.php/Hot_Fixes I''d be grateful. -chris -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html