lkml.org 
[lkml]   [2016]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Introspecting userns relationships to other namespaces?
    On Thu, Jul 07, 2016 at 11:54:54PM -0700, Andrew Vagin wrote:
    > On Thu, Jul 07, 2016 at 10:26:50PM -0700, W. Trevor King wrote:
    > > On Thu, Jul 07, 2016 at 08:26:47PM -0700, James Bottomley wrote:
    > > > On Thu, 2016-07-07 at 20:00 -0700, Andrew Vagin wrote:
    > > > > On Thu, Jul 07, 2016 at 07:16:18PM -0700, Andrew Vagin wrote:
    > > > > > I think we can show all required information in fdinfo. We open
    > > > > > a namespaces file (/proc/pid/ns/N) and then read
    > > > > > /proc/pid/fdinfo/X for it.
    > > > >
    > > > > Here is a proof-of-concept patch.
    > > > > …
    > > > > In [2]: fd = os.open("/proc/self/ns/pid", os.O_RDONLY)
    > > > >
    > > > > In [3]: print open("/proc/self/fdinfo/%d" % fd).read()
    > > > > pos: 0
    > > > > flags: 0100000
    > > > > mnt_id: 2
    > > > > userns: 4026531837
    > > > >
    > > > > In [4]: print "/proc/self/ns/user -> %s" %
    > > > > os.readlink("/proc/self/ns/user")
    > > > > /proc/self/ns/user -> user:[4026531837]
    > > >
    > > > can't you just do
    > > >
    > > > readlink /proc/self/ns/user | sed 's/.*\[\(.*\)\]/\1/'
    > > …
    > > If you only put one level in fdinfo, you're stuck if one of the
    > > namespaces involved has neither bind mounts nor a PID to give you
    > > handle on it [1]. And if you want to put that whole ancestor tree in
    > > fdinfo, you have to come up with some way to handle the two-parent
    > > branching.
    >
    > I think it's a bad idea to draw a tree in fdinfo. Why do we want to know
    > this hierarchy? Probably we will want to access these namespaces (setns),
    > in this case we need to have a way to open them.
    >
    > Maybe we need to extend functionality of the nsfs filesystem
    > (somethink like /proc/PID for namespaces)?

    A similar idea came up during the PID-translation brainstorming [1],
    but I'm not sure if anything ever came of that. Once you're dealing
    with a separate pseudo-filesystem, it seems easier to decouple it from
    proc and just make a mountable namespace-hierarchy filesystem (like we
    have mountable cgroup hierarchy filesystems). That also gets you an
    opt-in playground while the details of the nsfs filesystem view are
    worked out. Are you imagining something like:

    $ tree .
    .
    ├── mnt{inum}
    │   └── user -> ../user{inum}
    ├── pid{inum}
    │   ├── pid{inum}
    │   │   └── user -> ../../user{inum}/user{inum}
    │   └── user -> ../user{inum}
    └── user{inum}
    └── user{inum}

    Cheers,
    Trevor

    [1]: http://thread.gmane.org/gmane.linux.kernel.containers/28105/focus=28164
    Subject: RE: [RFC]Pid conversion between pid namespace
    Date: Fri, 25 Jul 2014 10:01:45 +0000
    Message-ID: <5871495633F38949900D2BF2DC04883E56C7A2@G08CNEXMBPEKD02.g08.fujitsu.local>

    --
    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
    [unhandled content-type:application/pgp-signature]
    \
     
     \ /
      Last update: 2016-07-08 10:01    [W:2.194 / U:0.220 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site