[RFC] AUFS disabled for 12.04
apw at shadowen.org
apw at shadowen.org
Fri Mar 2 12:16:17 UTC 2012
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 at garubtosh:~/tmp$ touch 3
> > gary at garubtosh:~/tmp$ chmod 0444 3
> > gary at 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.
More information about the ubuntu-devel