Comment 32 for bug 1476662

The patch above still causes some regressions. The fix may be simple, but it's getting late.

The issue, I hope, is that we demand that we be able to inspect the mount target, to detect whether it is a symlink. This is more restrictive than 'mount' is. I can, from a non-init userns, mount a directory over /root even though i can't look at /root.

One of the failures I'm seeing is with $containerroot/proc/sysrq-trigger, which is
--w------- 1 root root 0 Sep 16 23:47 /proc/sysrq-trigger

Since a symbolic cannot have its permissions changed, I think we can assume that if we get EPERM on a final part of a link, we can allow the mount.

However, since we cannot then open the file/dir (to fchdir to or to mount onto /proc/self/fd), dealing with this complicates the whole thing.