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 [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
