Re: open_tree, and bind-mounting directories across mount namespaces

[Christian Brauner <brauner@kernel.org>]

On Sat, Nov 01, 2025 at 12:01:38AM +0100, Snaipe wrote:
> Hi folks,
> 
> (Disclaimer: I'm not a kernel developer)
> 
> I'm currently playing around with the new mount API, on Linux 6.17.6.
> One of the things I'm trying to do is to write a program that unshares
> its mount namespace and receives a directory file descriptor via an
> unix socket from another program that exists in a different mount
> namespace. The intent is to have a program that has access to data on
> a filesystem that is not normally accessible to other unprivileged
> programs, and have that program give access to select directories by
> opening them with O_PATH and sending the fds over a unix socket.
> 
> One snag I'm currently hitting is that once I call open_tree(fd, "",
> OPEN_TREE_CLONE|AT_EMPTY_PATH|AT_RECURSIVE), the syscall returns
> EINVAL; I've bpftraced it back to __do_loopback's may_copy_tree check
> and it looks like it's impossible to do on dentries whose mount
> namespace is different that the current task's mount namespace.
> 
> I'm trying to understand the reasons this was put in place, and what
> it would take to enable the kind of use-case that I have. Would there
> be a security risk to relax this condition with some kind of open_tree
> flag?

In principle it's doable just like I made statmount() and listmount()
allow you to operate across mount namespaces.

If we do this I don't think we need a new flag as in your new example.
We just need open_tree() to support being called on foreign mounts
provided the caller is privileged over the target mount namespace and it
needs a consistent permission model and loads of tests. So no flags
needed imho.

I can start looking into this next week or you can give it your own
shot.