| Message ID | 20210316112257.2974212-1-christian.brauner@ubuntu.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | cachefiles: do not yet allow on idmapped mounts | expand |
diff --git a/fs/cachefiles/bind.c b/fs/cachefiles/bind.c index dfb14dbddf51..bd7eab9a0539 100644 --- a/fs/cachefiles/bind.c +++ b/fs/cachefiles/bind.c @@ -115,6 +115,10 @@ static int cachefiles_daemon_add_cache(struct cachefiles_cache *cache) if (ret < 0) goto error_open_root; + ret = -EINVAL; + if (mnt_user_ns(path.mnt) != &init_user_ns) + goto error_unsupported; + cache->mnt = path.mnt; root = path.dentry;
Based on discussion with David Howells my understanding of cachefiles and the cachefiles userspace daemon is that it creates a cache on a local filesystem (e.g. ext4, xfs etc.) for a network filesystem. The way this is done is by writing "bind" to /dev/cachefiles and pointing it to the directory to use as the cache. So from our offline discussion I gather that cachefilesd creates a cache on a local filesystem (ext4, xfs etc.) for a network filesystem. The way this is done is by writing "bind" to /dev/cachefiles and pointing it to a directory to use as the cache. Currently this directory can technically also be an idmapped mount but cachefiles aren't yet fully aware of such mounts and thus don't take the idmapping into account. This could leave users confused as the ownership of the files wouldn't match to what they expressed in the idmapping. So let's not allow this for now and only make cachefiles aware of idmapped mounts after it's current rewrite/rework is done. Link: https://lore.kernel.org/lkml/20210303161528.n3jzg66ou2wa43qb@wittgenstein Cc: David Howells <dhowells@redhat.com> Cc: linux-cachefs@redhat.com Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com> --- fs/cachefiles/bind.c | 4 ++++ 1 file changed, 4 insertions(+) base-commit: 1e28eed17697bcf343c6743f0028cc3b5dd88bf0