linux-kernel - [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1468520419-28220-1-git-send-email-avagin@openvz.org>
Date:	Thu, 14 Jul 2016 11:20:14 -0700
From:	Andrey Vagin <avagin@...nvz.org>
To:	linux-kernel@...r.kernel.org
Cc:	linux-api@...r.kernel.org, containers@...ts.linux-foundation.org,
	criu@...nvz.org, linux-fsdevel@...r.kernel.org,
	Andrey Vagin <avagin@...nvz.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
	"W. Trevor King" <wking@...mily.us>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Serge Hallyn <serge.hallyn@...onical.com>
Subject: [PATCH 0/5 RFC] Add an interface to discover relationships between namespaces

Each namespace has an owning user namespace and now there is not way
to discover these relationships.

Pid and user namepaces are hierarchical. There is no way to discover
parent-child relationships too.

Why we may want to know relationships between namespaces?

One use would be visualization, in order to understand the running system.
Another would be to answer the question: what capability does process X have to
perform operations on a resource governed by namespace Y?

One more use-case (which usually called abnormal) is checkpoint/restart.
In CRIU we age going to dump and restore nested namespaces.

There [1] was a discussion about which interface to choose to determing
relationships between namespaces.

Eric suggested to add two ioctl-s [2]:
> Grumble, Grumble.  I think this may actually a case for creating ioctls
> for these two cases.  Now that random nsfs file descriptors are bind
> mountable the original reason for using proc files is not as pressing.
>
> One ioctl for the user namespace that owns a file descriptor.
> One ioctl for the parent namespace of a namespace file descriptor.

Here is an implementaions of these ioctl-s.

[1] https://lkml.org/lkml/2016/7/6/158
[2] https://lkml.org/lkml/2016/7/9/101

Cc: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: James Bottomley <James.Bottomley@...senPartnership.com>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc: "W. Trevor King" <wking@...mily.us>
Cc: Alexander Viro <viro@...iv.linux.org.uk>
Cc: Serge Hallyn <serge.hallyn@...onical.com>

--
2.5.5