Re: [RFC] AUFS disabled for 12.04
See bug number 1007089 overlayfs alters /proc/self/exe link(s), making result a dead link. Test script, from #40: ( set -e mkdir -p /mnt/test /tmp/usr mount none /mnt/test -t overlayfs -o lowerdir=/usr,upperdir=/tmp/usr /mnt/test/bin/tail -f /dev/null& ls -lart /proc/$!/exe kill $! umount /mnt/test rmdir /mnt/test /tmp/usr ) # If a red broken link to/bin/tail is printed then the bug exists. If the link points to /mnt/test/bin/tail then there is no bug in the currently running kernel. On 02/29/12 10:57, Leann Ogasawara wrote: > Hi All, > > Early in the Precise Pangolin 12.04 development cycle, we disabled > support for AUFS in the kernel. This decision was made at UDS. The > reasoning behind this decision included: > > * AUFS is not upstream. Despite previous efforts from it's > maintainer, it does not appear it will ever land upstream. > * AUFS is a maintenance burden for the Ubuntu Kernel Team due to > the fact that it is not upstream. > * Support for OverlayFS has been available since Oneiric. We have > been encouraging migration to OverlayFS. The installer has > already transitioned to using OverlayFS (which was done in > Oneiric). > > We've noted the disablement of AUFS in every Technical Overview for each > 12.04 milestone. However, we felt it was also necessary to send a > widespread notification. > > For anyone struggling with the dropped support of AUFS, we would like to > hear from you. We'd be particularly interested in specific use case > scenarios where OverlayFS is not meeting the needs/requirements > previously met by AUFS. We are already aware of some inotify issues > with OverlayFS [1]. We are curious if there are any other specific > cases where people are experiencing issues with OverlayFS. We'd like to > gather any compelling evidence to support the requests to re-enable > AUFS. > > Thanks, > Leann Ogasawara > > [1] https://lkml.org/lkml/2012/2/28/223 > > -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] AUFS disabled for 12.04
On 03/02/12 08:58, Tim Gardner wrote: In light of the concerns about overlayfs being sufficiently cooked in time for Precise, Andy Whitcroft and I have decided to re-enable aufs. Thank you, that's helpful and comforting. We will continue to advocate for dropping aufs in favor of a sufficient upstream solution at each development cycle. This means that aufs _will_ disappear in future backported LTS kernels. In other words, don't bet your business on aufs. I am speaking directly to the lxc and server folks. aufs has _one_ maintainer, is enormously complex, is difficult to integrate with each new kernel version, and will _never_ be accepted upstream. Understood. We'll continue to try pushing forward with overlayfs ourselves, but we'll also now have a backup plan, which we appreciate. Hopefully other current aufs users will be in a similar boat. Gary -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] AUFS disabled for 12.04
On 03/01/2012 03:08 PM, Gary Poster wrote: Hi. aufs was reliable for us on Oneiric when creating ephemeral lxc instances based on an underlying template. The most recent overlayfs issue that we discovered is today's https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944386 The summary is that, within an overlayfs, this fails: gary@garubtosh:~/tmp$ touch 3 gary@garubtosh:~/tmp$ chmod 0444 3 gary@garubtosh:~/tmp$ ln 3 4 ln: failed to create hard link `4' => `3': Operation not permitted That error makes xvfb unable to start, in this particular case. I'd feel a *lot* more comfortable if aufs were still around, in case we end up not finding the next overlayfs bug until it is too late for our project's delivery. Thank you, Gary In light of the concerns about overlayfs being sufficiently cooked in time for Precise, Andy Whitcroft and I have decided to re-enable aufs. We will continue to advocate for dropping aufs in favor of a sufficient upstream solution at each development cycle. This means that aufs _will_ disappear in future backported LTS kernels. In other words, don't bet your business on aufs. I am speaking directly to the lxc and server folks. aufs has _one_ maintainer, is enormously complex, is difficult to integrate with each new kernel version, and will _never_ be accepted upstream. rtg -- Tim Gardner tim.gard...@canonical.com -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] AUFS disabled for 12.04
On Fri, Mar 02, 2012 at 12:56:13AM -0800, Kees Cook wrote: > Hi Gary, > > On Thu, Mar 01, 2012 at 05:08:36PM -0500, Gary Poster wrote: > > aufs was reliable for us on Oneiric when creating ephemeral lxc > > instances based on an underlying template. The most recent > > overlayfs issue that we discovered is today's > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944386 > > > > The summary is that, within an overlayfs, this fails: > > > > gary@garubtosh:~/tmp$ touch 3 > > gary@garubtosh:~/tmp$ chmod 0444 3 > > gary@garubtosh:~/tmp$ ln 3 4 > > ln: failed to create hard link `4' => `3': Operation not permitted > > > > That error makes xvfb unable to start, in this particular case. > > > > I'd feel a *lot* more comfortable if aufs were still around, in case > > we end up not finding the next overlayfs bug until it is too late > > for our project's delivery. > > At the cost of some security, you can disable this specific restriction via > the sysctl knob: > echo 0 > /proc/sys/kernel/yama/protected_nonaccess_hardlinks > > After the failure, you can see the (unhelpful) report in dmesg: > [ 354.737598] non-accessible hardlink creation was attempted by: ln (fsuid > 1000) > > However, I think the bug is actually with overlayfs. A similar problem was > seen with aufs, but Andy fixed those. The bug that time was actually a bug in Yama which we resolved, it was not honouring the filesytems permissions op. But that fix is definatly in the yama in Precise (just confirmed). > Based on the situation needed to reproduce it (non-writable), I think the > condition that is failing in the hardlink restriction logic is this line: > cred->fsuid != inode->i_uid > But that makes no sense to me. > > Andy, is unionfs lying about the i_uid in the filesystem? I thought if that was the issue the fsuid would be off in the report above. /me will investigate the bug. -apw -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] AUFS disabled for 12.04
Hi Gary, On Thu, Mar 01, 2012 at 05:08:36PM -0500, Gary Poster wrote: > aufs was reliable for us on Oneiric when creating ephemeral lxc > instances based on an underlying template. The most recent > overlayfs issue that we discovered is today's > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944386 > > The summary is that, within an overlayfs, this fails: > > gary@garubtosh:~/tmp$ touch 3 > gary@garubtosh:~/tmp$ chmod 0444 3 > gary@garubtosh:~/tmp$ ln 3 4 > ln: failed to create hard link `4' => `3': Operation not permitted > > That error makes xvfb unable to start, in this particular case. > > I'd feel a *lot* more comfortable if aufs were still around, in case > we end up not finding the next overlayfs bug until it is too late > for our project's delivery. At the cost of some security, you can disable this specific restriction via the sysctl knob: echo 0 > /proc/sys/kernel/yama/protected_nonaccess_hardlinks After the failure, you can see the (unhelpful) report in dmesg: [ 354.737598] non-accessible hardlink creation was attempted by: ln (fsuid 1000) However, I think the bug is actually with overlayfs. A similar problem was seen with aufs, but Andy fixed those. Based on the situation needed to reproduce it (non-writable), I think the condition that is failing in the hardlink restriction logic is this line: cred->fsuid != inode->i_uid But that makes no sense to me. Andy, is unionfs lying about the i_uid in the filesystem? -Kees -- Kees Cook -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: [RFC] AUFS disabled for 12.04
Hi. aufs was reliable for us on Oneiric when creating ephemeral lxc instances based on an underlying template. The most recent overlayfs issue that we discovered is today's https://bugs.launchpad.net/ubuntu/+source/linux/+bug/944386 The summary is that, within an overlayfs, this fails: gary@garubtosh:~/tmp$ touch 3 gary@garubtosh:~/tmp$ chmod 0444 3 gary@garubtosh:~/tmp$ ln 3 4 ln: failed to create hard link `4' => `3': Operation not permitted That error makes xvfb unable to start, in this particular case. I'd feel a *lot* more comfortable if aufs were still around, in case we end up not finding the next overlayfs bug until it is too late for our project's delivery. Thank you, Gary -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
[RFC] AUFS disabled for 12.04
Hi All, Early in the Precise Pangolin 12.04 development cycle, we disabled support for AUFS in the kernel. This decision was made at UDS. The reasoning behind this decision included: * AUFS is not upstream. Despite previous efforts from it's maintainer, it does not appear it will ever land upstream. * AUFS is a maintenance burden for the Ubuntu Kernel Team due to the fact that it is not upstream. * Support for OverlayFS has been available since Oneiric. We have been encouraging migration to OverlayFS. The installer has already transitioned to using OverlayFS (which was done in Oneiric). We've noted the disablement of AUFS in every Technical Overview for each 12.04 milestone. However, we felt it was also necessary to send a widespread notification. For anyone struggling with the dropped support of AUFS, we would like to hear from you. We'd be particularly interested in specific use case scenarios where OverlayFS is not meeting the needs/requirements previously met by AUFS. We are already aware of some inotify issues with OverlayFS [1]. We are curious if there are any other specific cases where people are experiencing issues with OverlayFS. We'd like to gather any compelling evidence to support the requests to re-enable AUFS. Thanks, Leann Ogasawara [1] https://lkml.org/lkml/2012/2/28/223 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
