On Thu, Mar 20, 2025 at 01:49:25PM +0000, David Howells wrote: > Christian Brauner <brauner@xxxxxxxxxx> wrote: > > > > > It also uses the lookup_one_len() family of functions which implicitly > > > > use &nop_mnt_idmap. This mixture of implicit and explicit could be > > > > confusing. When we eventually update cachefiles to support idmap mounts > > > > it > > > > > > Is that something we ever plan to do? > > > > It should be pretty easy to do. I just didn't see a reason to do it yet. > > > > Fwiw, the cache paths that cachefiles uses aren't private mounts like > > overlayfs does it, i.e., cachefiles doesn't do clone_private_mount() before > > stashing cache->mnt. ... > > This is probably something cachefilesd needs to do in userspace before telling > the kernel through /dev/cachefiles where to find the cache. Afaict, I don't think it matters whether the mount is actually attached to a mount namespace so cachefilesd could just do: fd_tree = open_tree(AT_FDCWD, "/path/to/cache", AT_EMPTY_PATH | OPEN_TREE_CLONE); and use the detached mount for all cachefilesd interactions.
