[CRIU] Introspecting userns relationships to other namespaces?

[W. Trevor King]

On Fri, Jul 08, 2016 at 01:38:19PM -0700, Andrew Vagin wrote:
> What do you think about the idea to mount nsfs and be able to look up
> any alive namespace by inum:
>
>   $ tree .
>   .
>   ├── mnt{inum}
>   │   └── user -> ../user{inum}
>   ├── pid{inum}
>   │   ├── pid{inum}
>   │   │   └── user -> ../../user{inum}/user{inum}
>   │   └── user -> ../user{inum}
>   └── user{inum}
>       └── user{inum}
>
> https://lkml.org/lkml/2016/7/8/59
>
> I think it solves all requirements which were mentioned in this thread.

It may need an additional entry per directory for the bit you setns.
Maybe ‘handle’?

  $ tree .
  .
  ├── mnt{inum}
  │   ├── handle -> mnt:[{inum}]
  │   └── user -> ../user{inum}
  …

but that's not a major revision.

> On Fri, Jul 08, 2016 at 07:35:33AM -0700, James Bottomley wrote:
> > On Fri, 2016-07-08 at 02:44 -0500, Eric W. Biederman wrote:
> > > Starting with 4.8 we are also going to need to be able to
> > > retrieve the user namespace owner of filesystems.  That will be
> > > an interesting mix.
> >
> > This is per mount point, isn't it? so it can't be in /proc/fs/ and
> > it would have to be per local mount tree.  Yes, that is a bit
> > nasty.  Sounds like we might need to unfold mount or mountinfo
> > into something that has one directory per entry?
>
> If we will be able to look up namespaces in nsfs by inum, we can
> print an userns inum in mountinfo.

With the tree view you can find a namespace by inum (if it's one of
your descendants), but it's not going to be particularly efficient
(you'll have to walk the tree).  Folks that need to do that quickly
can index the tree (which would be fairly straightforward if the nsfs
mount supports inotify), but it would be nice to have a more elegant
solution for this use-case.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160708/93b1b0b5/attachment.sig>