[RFC] AUFS disabled for 12.04

[apw at shadowen.org]

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.

-apw