linux-kernel - [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-next>] [day] [month] [year] [list]

Message-Id: <1346946994-21286-1-git-send-email-apw@canonical.com>
Date:	Thu,  6 Sep 2012 16:56:32 +0100
From:	Andy Whitcroft <apw@...onical.com>
To:	Miklos Szeredi <miklos@...redi.hu>,
	Andy Whitcroft <apw@...onical.com>
Cc:	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	mszeredi@...e.cz
Subject: [RFC PATCH 0/2] issues with NFS filesystems as lower layer

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