Re: [CRIU] Introspecting userns relationships to other namespaces?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 12, 2016 at 05:08:43PM -0700, Andrew Vagin wrote:
> Here is a patch to get an owning user namespace:
> https://github.com/avagin/linux-task-diag/commit/7fad8ff3fc4110bebf0920cec2388390b3bd2238
> https://github.com/avagin/linux-task-diag/commit/2663bc803d324785e328261f3c07a0fef37d2088
>
> Here is an example how it looks from user-space:
> https://github.com/avagin/linux-task-diag/blob/namespaces/tools/testing/selftests/nsfs/owner.c#L49

Overall this looks good to me (I left a handful of uninformed comments
inline ;).

It doesn't make it easy to walk leafward, but it doesn't look like the
kernel has a convenient way to list child namespaces either.
Something like /proc/<pid>/task/<tid>/children (with
CONFIG_PROC_CHILDREN) for namespaces would make it easier to get a
complete system overview (as far as your credentials and position in
the namespace hierarchies allow).  But looking at the
CONFIG_PROC_CHILDREN implementation doesn't make me all that excited
about mimicking it for namespaces ;).

You can still brute-force it in userspace by walking the root-most
procfs's you can find and peeking at all the /proc/<pid>/ns/… entries
(but yuck ;).  With mount and other namespaces not being hierarchical,
the “leafword” idea may not be all that useful anyway, but having a
more compact collection of mount namepaces (say) that you know about
would be nice.  Where “know about” should probably means “know it
exists” but not necessarily “have permission to enter”.  Still,
getting that figured out can happen independently to this parent/owner
work.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Attachment: signature.asc
Description: OpenPGP digital signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux