linux-kernel - Re: [RFC PATCH 0/2] issues with NFS filesystems as lower layer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 7 Sep 2012 08:35:36 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Andy Whitcroft <apw@...onical.com>
Cc:	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 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
ignoring them should be the right thing to do.

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

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