[GSOC][namespace Support]

[WeiFeng Lai]

> How do you expect to do this, taking into account the fact that strace
>process doesn't normally have CAP_SYS_ADMIN?
>Note that stable upstream kernels do not normally accept new features.
>And downstream kernels are also quite hesitant in doing so.

Thank you for a reply, I will summarize the previous misunderstandings:
1. strace does not have CAP_SYS_ADMIN privileges in most cases, and
mounting /proc requires root privileges.
    Therefore, it is not desirable to mount /proc continuously.
2. The method of adding a system call is difficult to be passed upstream
kernel or downstream kernel, so the previous idea is really unrealistic.

>There are NSFS_* ioctls present that can be used for (PID) namespace
>tree traversal[3]. Along with inspection of *id fields in
>/proc/<pid>/status, the available information information is sufficient
>for deriving the needed PID in strace's PID NS (having /proc mounted
>with different PID NS quite complicates things but still manageable).
>[1] https://lkml.org/lkml/2018/3/13/1544
>[2] https://lkml.org/lkml/2017/10/13/177
>[3] http://blog.man7.org/2016/12/introspecting-namespace-relationships.html

Thanks for your excellent documents which include many elegant thoughts.
I think starting with /proc/[pid]/ns/* is better one after reading over
these documents.
Through reading a lot of articles to understand the structure of the
namespace, the operation, and the new features of kernel 4.9 (I only
contacted kernel 3.X and 4.1 before, but I'm downloading kernel 4.9), I
know a truth that many things that can be used to display PIDs in different
namespaces.

Some of my opinions as follows:
In this article by Michael Kerrisk (link:
http://blog.man7.org/2016/12/introspecting-namespace-relationships.html),
the relationships and features between different namespaces are described.
Describes one of the important features of linux kernel 4.9: Support for
binding a (unmounted) object in the namespace using the file descriptor fd.
With this feature, we can check the /proc/[pid]/ns/* files for all
processes and build a map which contains all processes in the
pid_namespaces and reflects hierarchical pid_namespace, the use of this map
can be realized that all processes on the system can discover the PID and
user namespace structure hierarchy on a live system.
Referring to the source code in the article with the Go language (link:
http://blog.man7.org/2016/12/introspecting-namespace-relationships.html), I
think what I can do at the moment is to use the knowledge from "Introduce
to algorithm" and other Data Structures before learning, and use those
knowledge to optimize the retrieval process.
Is there anything wrong with my understanding of those documents?
Is there any better suggestion?

BWT, there is another problem I don't how to solve it. it needs
CAP_SYS_ADMIN when system check the contents of  /proc/[pid]/ns/* .
that means strace need CAP_SYS_ADMIN  privileges still. Is there some
better ways to solve this problem?

2018-03-17 14:56 GMT+08:00 Eugene Syromiatnikov <esyr at redhat.com>:

> On Sat, Mar 17, 2018 at 10:52:39AM +0800, WeiDeng Lai wrote:
> > mounting /proc whenever we enter the new name space.
>
> How do you expect to do this, taking into account the fact that strace
> process doesn't normally have CAP_SYS_ADMIN?
>
> > To complete this requirement,we can make a try to add a
> > new kernel API for trans_pid between different pid_namespaces,such as
> patch
> > in link: * https://lkml.org/lkml/2018/3/6/593
> > <https://lkml.org/lkml/2018/3/6/593> *.
>
> Note Eric Biederman's comments there[1]. Please also refer to the
> discussion related to the previous version of the patch[2]. How do you
> expect to address the objections raised there in order to have the API
> accepted in the kernel's upstream?
>
> > a few days ago,I talk with my  seniors of community,we have a consistent
> > point that add a new kernel API may a good idea,we can apply patch on
> later
> > kernel versions,and modify it so that patch can apply on 3.x to now.If it
> > make sense,I'll do this.
>
> Note that stable upstream kernels do not normally accept new features.
> And downstream kernels are also quite hesitant in doing so.
>
> > I don't hatch other methods,can someone provide some information or
> > documents for my reference?
>
> There are NSFS_* ioctls present that can be used for (PID) namespace
> tree traversal[3]. Along with inspection of *id fields in
> /proc/<pid>/status, the available information information is sufficient
> for deriving the needed PID in strace's PID NS (having /proc mounted
> with different PID NS quite complicates things but still manageable).
>
> [1] https://lkml.org/lkml/2018/3/13/1544
> [2] https://lkml.org/lkml/2017/10/13/177
> [3] http://blog.man7.org/2016/12/introspecting-namespace-
> relationships.html
> --
> Strace-devel mailing list
> Strace-devel at lists.strace.io
> https://lists.strace.io/mailman/listinfo/strace-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20180318/ba594fa1/attachment.html>