When mounting an overlayfs filesystem in a user namespace we encounter
issues with whiteout handling. Specifically the local namespace root
user is not able to manipulate the "trusted." hierachy to install the
xattr marking the whiteouts.
In the preceeding discussion it was noted that we should really be avoiding
the permissions checks in these cases, as we have already validated that
the operation is permissible.
It was suggested we could use the __vfs_getxattr_noperm interfaces for
this, and I did spend some time prototyping this. However it requires
us to expose at least two new interfaces to allow setting and getting
these without checks. Overall it seemed excessive given that we were
already indicating our willingness to take on additional capabilities to
get these operations done. That lead to a rethink, and the two alternate
patches which follow:
1) overlayfs: switch to the init user namespace for xattr operations:
This first patch solves the issue by dropping back into the init_user_ns
for these operations, effectivly avoiding the namespace issues.
2) overlayfs: use kernel service credentials for copy up and xattr manipulations:
This second patch takes a more radical approach. As we are willing to
grab all and any permissions we need to make these operations succeed,
it simply grabs full kernel rights via prepare_kernel_cred(NULL).
I personally favour the latter approach as it allows us to remove a number
of essentially arbitrary capability grabs, though it could be argued that
the former patch better documents what is its we actually need.
We have done some basic testing on both and they seem to work as expected.
Comments, thoughts?
-apw
Andy Whitcroft (1):
UBUNTU: ubuntu: overlayfs20 -- switch to the init user namespace for
xattr operations
fs/overlayfs/copy_up.c | 4 ++++
fs/overlayfs/dir.c | 23 +++++++++++++++++++----
fs/overlayfs/readdir.c | 7 +++++++
fs/overlayfs/super.c | 5 ++++-
4 files changed, 34 insertions(+), 5 deletions(-)
--
1.9.0
--
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
