During some testing here we discovered that we could not successfully
use a NFS as the lower layer for overlayfs. There are two separate issues:
Firstly when using an NFSv4 lower layer we tickle an issue when copying
up the xattrs for the underlying file. NFS uses an xattr system.nfs4_acl
which the upper layer will not store (ext4 for example). This triggers
an EOPNOTSUPP error when trying to copy up the xattrs for the file,
preventing the file being written. I am a little unclear as to whether it
makes sense to generally ignore xattrs we cannot store in the upper layer,
this is based on the assumption the person creating the mount knew what
they were combining. The first patch (for discussion) following this
email avoids this issue by ignoring the xattr if it is not storable.
Secondly when using an NFSv3 R/O lower layer the filesystem permissions
check refuses permission to write to the inode which prevents us from
copying it up even though we have a writable upper layer. (With an ext4
lower layer the inode check will succeed if the inode is writable even
if the filesystem is not.) It is not clear what the right solution is
here. One approach is to check the inode permissions only (avoiding the
filesystem specific permissions op), but it is not clear we can rely on
these for all underlying filesystems. Perhaps this check should only be
used for NFS. Perhaps it needs to be a mount option. The second patch
(for discussion) following this email implements this, using the inode
permissions when the lowerlayer is read-only. This seems to work as
expected in my limited testing.
Comments on both approaches appreciated.
-apw
Andy Whitcroft (2):
ovl: copy_up_xattr may fail when the upper filesystem does not
support the same xattrs
overlayfs: when the underlying filesystem is read-only use inode
permissions
fs/namei.c | 36 ++++++++++++++++++++++++++++++++++++
fs/overlayfs/copy_up.c | 9 ++++++++-
fs/overlayfs/inode.c | 12 ++++++++++++
include/linux/fs.h | 1 +
4 files changed, 57 insertions(+), 1 deletion(-)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
