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

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

[Eric W. Biederman]

Christian Brauner <brauner@kernel.org> writes:

> Hey Linus,
>
> /* Summary */
> This contains substantial namespace infrastructure changes including a new
> system call, active reference counting, and extensive header cleanups.
> The branch depends on the shared kbuild branch for -fms-extensions
> support.

I am missing something.  From the description it looks like
you are making nested containers impossible once this feature
is adopted.  Because the container will be able to see all of
the other namespaces and thus to see outside of it's own namespace.

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?

If you want nesting of containers the listing of namespaces very
much must be incomplete.

I haven't looked at reviewed or looked at the code yet because
the code was not posted in any of the usual places for container
development, nor was I copied.

Can you please describe how you are avoiding the namespace of namespaces
problem?


Eric

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

[Linus Torvalds]

On Mon, 1 Dec 2025 at 11:06, Eric W. Biederman <ebiederm@xmission.com> 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

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

[Christian Brauner]

On Tue, Dec 02, 2025 at 09:00:57AM -0800, Linus Torvalds wrote:
> On Mon, 1 Dec 2025 at 11:06, Eric W. Biederman <ebiederm@xmission.com> 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:

After last year's round I've caught another lung infection so I'm a bit
incapacitated and not working. Visibility is currently based on the user
namespace. It's possible to list all namespaces that are owned by a
given user namespaces. So a caller in an unprivileged container is only
able to list namespaces that they directly own or namespaces owned by
descendant namespaces. That's tracked in the namespace tree. The
self-tests verify this as well. So it is not possible to break out of
that hierarchy. As this is expressily an introspection system call it
allows to list sibling namespaces owned by the same user namespace ofc
as its tailored for container managers. This will be used in
high-privileged container managers and in systemd for service
supervision so if there's any concerns that the current standard access
regulation and seccomp() isn't enough I'm more than happy to require
global CAP_SYS_ADMIN.