linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@canonical.com>
To: Miklos Szeredi <miklos@szeredi.hu>, Andy Whitcroft <apw@canonical.com>
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	mszeredi@suse.cz
Subject: [RFC PATCH 0/2] issues with NFS filesystems as lower layer
Date: Thu,  6 Sep 2012 16:56:32 +0100	[thread overview]
Message-ID: <1346946994-21286-1-git-send-email-apw@canonical.com> (raw)

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


             reply	other threads:[~2012-09-06 15:56 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-06 15:56 Andy Whitcroft [this message]
2012-09-06 15:56 ` [RFC PATCH 1/2] ovl: ovl_copy_up_xattr may fail when the upper filesystem does not support the same xattrs Andy Whitcroft
2012-09-06 15:56 ` [PATCH 2/2] overlayfs: when the underlying filesystem is read-only use inode permissions Andy Whitcroft
2012-09-07  6:35 ` [RFC PATCH 0/2] issues with NFS filesystems as lower layer Miklos Szeredi
2012-09-07 19:38   ` J. Bruce Fields
2012-09-11 20:56     ` Miklos Szeredi
2012-09-11 21:44       ` J. Bruce Fields
2012-09-12 15:20         ` Miklos Szeredi
2012-09-12 16:07           ` J. Bruce Fields

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1346946994-21286-1-git-send-email-apw@canonical.com \
    --to=apw@canonical.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=mszeredi@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).