Faulty interaction between open_tree_clone and OPEN_TREE_NAMESPACE?

Faulty interaction between open_tree_clone and OPEN_TREE_NAMESPACE?

[Gabriel Sakash]

Hello.

Christian Brauner, I have CC'd you since you're the author of
https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-
bfb24c7b061f@kernel.org/.

Due to Arch Linux updating the kernel to 7.0.2 today, I have been able to test
the new OPEN_TREE_NAMESPACE open_tree flag on my main workstation.
However, I have found that it and open_tree_attr do not work together.

At the end is the C program I used to test the following.
I expect that the output is something like:
TARGET SOURCE                    FSTYPE OPTIONS PROPAGATION
/               /dev/nvme0n1p2[/@] btrfs         <options> private
But I get:
open_tree_attr /: Operation not permitted

Using "plain" open_tree works as expected. I have narrowed down 3 issues:

1:
fs/namespace.c:5196 => wants_mount_setattr(...) to check if the attribute
changes are sound.
fs/namespace.c:5101 => may_mount() to check if the permission are met

may_mount is:
return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN);

Because this is from open_tree_attr, the process has not entered the new mount
namespace yet. This will check if the process has CAP_SYS_ADMIN in the init
user namespace, which it won't.

2:
fs/namespace.c:5198 => do_mount_setattr(&file->f_path, ...)
fs/namespace.c:5198 => path_mounted(path)

This attempts to make the mount attribute changes on the path of the namespace
"file", and not to the (root) mount in the new mount namespace. It will fail on
path_mounted because the namespace "file" won't be the root of the NS FS.

3:
fs/namespace.c:4952 => !anon_ns_root(mnt) && !check_mnt(mnt)

This checks if the mount is anonymous (it won't be), and if not,that
it's in the same
mount namespace as the process (also false).
It appears that the current mount attribute calls aren't set up to handle
mount namespaces different from that of the current process.

This issue is still prevalent when running a VM with a kernel built off of
Linus's master branch. Apologies if this is already known about.

Thank you for your time and good day.



C code to reproduce:
==================================================
#include <fcntl.h>
#include <linux/mount.h>
#include <sched.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mount.h>
#include <syscall.h>
#include <unistd.h>

// linux-api-headers on Arch is only up to 6.19 so /usr/include/linux/mount.h
// doesn't have this constant yet
#define OPEN_TREE_NAMESPACE (1 << 1)

int open_tree_attr(int dirfd, const char *path, unsigned int flags,
                   struct mount_attr *attr) {
    return (int) syscall(SYS_open_tree_attr, dirfd, path, flags, attr,
                         sizeof(struct mount_attr));
}

int main(void) {
    if (unshare(CLONE_NEWUSER) != 0) {
        perror("unsharing user namespace");
        return EXIT_FAILURE;
    }

    struct mount_attr attrs = {.propagation = MS_PRIVATE};

    const int namespace_fd = open_tree_attr(AT_FDCWD, "/",
        OPEN_TREE_CLOEXEC | OPEN_TREE_NAMESPACE, &attrs);

    if (namespace_fd < 0) {
        perror("open_tree_attr /");
        return EXIT_FAILURE;
    }

    if (setns(namespace_fd, CLONE_NEWNS) != 0) {
        perror("setns");
        return EXIT_FAILURE;
    }

    close(namespace_fd);

    char *args[] = {
        "/usr/bin/findmnt",
        "--kernel=listmount", // Needed due to proc not being mounted
        "-o", "+PROPAGATION",
        NULL
    };

    execv(args[0], args);

    perror("exec");
    return EXIT_FAILURE;
}
==================================================

Re: Faulty interaction between open_tree_clone and OPEN_TREE_NAMESPACE?

[Christian Brauner]

On Thu, Apr 30, 2026 at 12:33:47AM -0400, Gabriel Sakash wrote:
> Hello.
> 
> Christian Brauner, I have CC'd you since you're the author of
> https://lore.kernel.org/all/20251229-work-empty-namespace-v1-0-
> bfb24c7b061f@kernel.org/.
> 
> Due to Arch Linux updating the kernel to 7.0.2 today, I have been able to test
> the new OPEN_TREE_NAMESPACE open_tree flag on my main workstation.
> However, I have found that it and open_tree_attr do not work together.
> 
> At the end is the C program I used to test the following.
> I expect that the output is something like:
> TARGET SOURCE                    FSTYPE OPTIONS PROPAGATION
> /               /dev/nvme0n1p2[/@] btrfs         <options> private
> But I get:
> open_tree_attr /: Operation not permitted
> 
> Using "plain" open_tree works as expected. I have narrowed down 3 issues:
> 
> 1:
> fs/namespace.c:5196 => wants_mount_setattr(...) to check if the attribute
> changes are sound.
> fs/namespace.c:5101 => may_mount() to check if the permission are met
> 
> may_mount is:
> return ns_capable(current->nsproxy->mnt_ns->user_ns, CAP_SYS_ADMIN);
> 
> Because this is from open_tree_attr, the process has not entered the new mount
> namespace yet. This will check if the process has CAP_SYS_ADMIN in the init
> user namespace, which it won't.
> 
> 2:
> fs/namespace.c:5198 => do_mount_setattr(&file->f_path, ...)
> fs/namespace.c:5198 => path_mounted(path)
> 
> This attempts to make the mount attribute changes on the path of the namespace
> "file", and not to the (root) mount in the new mount namespace. It will fail on
> path_mounted because the namespace "file" won't be the root of the NS FS.
> 
> 3:
> fs/namespace.c:4952 => !anon_ns_root(mnt) && !check_mnt(mnt)
> 
> This checks if the mount is anonymous (it won't be), and if not,that
> it's in the same
> mount namespace as the process (also false).
> It appears that the current mount attribute calls aren't set up to handle
> mount namespaces different from that of the current process.
> 
> This issue is still prevalent when running a VM with a kernel built off of
> Linus's master branch. Apologies if this is already known about.
> 
> Thank you for your time and good day.

Thank you for this bug report. It has all the details we need. This is a
missing feature for open_tree_attr() for sure and should have been
merged alongside the original implementation. Thanks for pointing that
out. I'll send a fix for this.