Re: [GIT PULL 05/17 for v6.19] namespaces

On Mon, 1 Dec 2025 at 11:06, Eric W. Biederman <[email protected]> wrote:
>
> The reason such as system call has not been introduced in the past
> is because it introduces the namespace of namespace problem.
>
> How have you solved the namespace of namespaces problem?

So I think Christian would be better at answering this, but to a first
approximation I think the explanation from commit 76b6f5dfb3fd
("nstree: add listns()") gives some high-level rules:

    listns() respects namespace isolation and capabilities:

    (1) Global listing (user_ns_id = 0):
        - Requires CAP_SYS_ADMIN in the namespace's owning user namespace
        - OR the namespace must be in the caller's namespace context (e.g.,
          a namespace the caller is currently using)
        - User namespaces additionally allow listing if the caller has
          CAP_SYS_ADMIN in that user namespace itself
    (2) Owner-filtered listing (user_ns_id != 0):
        - Requires CAP_SYS_ADMIN in the specified owner user namespace
        - OR the namespace must be in the caller's namespace context
        - This allows unprivileged processes to enumerate namespaces they own
    (3) Visibility:
        - Only "active" namespaces are listed
        - A namespace is active if it has a non-zero __ns_ref_active count
        - This includes namespaces used by running processes, held by open
          file descriptors, or kept active by bind mounts
        - Inactive namespaces (kept alive only by internal kernel
          references) are not visible via listns()

but it would be very nice if you were to take a closer look at the
whole thing and make sure you're satisfied with it all.. Even just a
"overview scan" would be lovely.

            Linus