Message-ID: <20120907193825.GA4633@fieldses.org>
Date:	Fri, 7 Sep 2012 15:38:26 -0400
From:	"J. Bruce Fields" <bfields@...ldses.org>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Andy Whitcroft <apw@...onical.com>, linux-fsdevel@...r.kernel.org,
	linux-kernel@...r.kernel.org, mszeredi@...e.cz
Subject: Re: [RFC PATCH 0/2] issues with NFS filesystems as lower layer

On Fri, Sep 07, 2012 at 08:35:36AM +0200, Miklos Szeredi wrote:
> On Thu, Sep 6, 2012 at 5:56 PM, Andy Whitcroft <apw@...onical.com> wrote:
> > 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.
> 
> I don't know much about NFSv4 ACL's but I think it may be incompatible
> with POSIX ACLs in which case copying them up is not possible and

Right.  (You can try to map them; see fs/nfsd/nfs4acl.c; but it's
complicated and lossy.)

> ignoring them should be the right thing to do.

The ACLs are enforced by the server side, so this won't let you read or
write server data that you couldn't before.

And you also shouldn't be able to access the copied-up file in ways you
couldn't before as long as the lower filesystem is consulted about
permissions.

> > 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.

Then couldn't you for example end up circumventing ACLs on the
underlying file to access data cached by reads from another user on the
same system?

Is it possible to arrange that the check for a readonly filesystem be
done only by the vfs and not also by ->permission?

--b.

> > 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.
> 
> I fear that will create an inconsistency between the read-only and the
> non-read-only case, even though both should behave the same.
> 
> I think the cleanest would be to create a mount option to always use
> generic_permission (on both the lower and the upper fs).  That would
> give us two, slightly different, operating modes but each would be
> self consistent.
> 
> Thanks,
> Miklos
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists