All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vasily Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
To: Pavel Emelyanov <xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
Cc: Richard Weinberger
	<richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	Serge Hallyn
	<serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org>,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>
Subject: Re: [PATCH v2] /proc/pid/status: show all sets of pid according to ns
Date: Sat, 31 May 2014 10:07:13 +0400	[thread overview]
Message-ID: <20140531060713.GA5315@cachalot> (raw)
In-Reply-To: <53872DAD.1070502-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>

On Thu, May 29, 2014 at 16:53 +0400, Pavel Emelyanov wrote:
> On 05/29/2014 03:59 PM, Vasily Kulikov wrote:
> > On Thu, May 29, 2014 at 15:31 +0400, Pavel Emelyanov wrote:
> >> On 05/29/2014 03:12 PM, Vasily Kulikov wrote:
> >>> On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
> >>>> On 05/29/2014 09:59 AM, Vasily Kulikov wrote:
> >>>>> On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
> >>>>> ] We need a direct method of getting the pid inside containers.
> >>>>> ] If some issues occurred inside container guest, host user
> >>>>> ] could not know which process is in trouble just by guest pid:
> >>>>> ] the users of container guest only knew the pid inside containers.
> >>>>> ] This will bring obstacle for trouble shooting.
> >>>>>
> >>>>> A new syscall might complicate trouble shooting by admin.
> >>>>
> >>>> Pure syscall -- yes. What if we teach the ps and top utilities to show additional
> >>>> info? I think that would help.
> >>>
> >>> I like the idea with low level non-shell API which can be used by
> >>> utility like ps (or implementation of a new tool to work with complex
> >>> namespace hierarchies).  It should fit for troublesooting.  Then there
> >>> should be no reason to implement two different APIs for observation from
> >>> shell via FS and from applications.
> >>
> >> Maybe we can reuse the existing kcmp() system call? We would have to store
> >> the collected pid values in some hash/tree anyway, and kcmp() provides us
> >> good comparing function for doing this.
> >>
> >> Like we can call kcmp(pid1, pid2, KCMP_PID, nsfd1, nsfd2) which will mean
> >> "Are tasks with pid1 in namespace pointed by nsfd1 and with pid2 in namespace
> >> nsfd2 the same?"
> >>
> >> What do you think?
> > 
> > kcmp() is not needed, just compare inode numbers:
> > 
> >     # ls -il /proc/{43,self}/ns/mnt
> >     208182 lrwxrwxrwx 1 root root 0 мая   29 15:52 /proc/43/ns/mnt -> mnt:[4026531856]
> >     216556 lrwxrwxrwx 1 root root 0 мая   29 15:57 /proc/self/ns/mnt -> mnt:[4026531840]
> 
> But that's for comparing the namespaces, while I'm proposing the kcmp to
> check for PIDs.

Hm, right.

What about the following solution: export global process ID (PID in
init ns) which is visible inside of any namespace.  Then you can compare
numbers regardless in what namespace you are.

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments
_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/containers

WARNING: multiple messages have this Message-ID (diff)
From: Vasily Kulikov <segoon@openwall.com>
To: Pavel Emelyanov <xemul@parallels.com>
Cc: Richard Weinberger <richard.weinberger@gmail.com>,
	containers@lists.linux-foundation.org,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	linux-kernel@vger.kernel.org, Oleg Nesterov <oleg@redhat.com>,
	David Howells <dhowells@redhat.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH v2] /proc/pid/status: show all sets of pid according to ns
Date: Sat, 31 May 2014 10:07:13 +0400	[thread overview]
Message-ID: <20140531060713.GA5315@cachalot> (raw)
In-Reply-To: <53872DAD.1070502@parallels.com>

On Thu, May 29, 2014 at 16:53 +0400, Pavel Emelyanov wrote:
> On 05/29/2014 03:59 PM, Vasily Kulikov wrote:
> > On Thu, May 29, 2014 at 15:31 +0400, Pavel Emelyanov wrote:
> >> On 05/29/2014 03:12 PM, Vasily Kulikov wrote:
> >>> On Thu, May 29, 2014 at 13:07 +0400, Pavel Emelyanov wrote:
> >>>> On 05/29/2014 09:59 AM, Vasily Kulikov wrote:
> >>>>> On Wed, May 28, 2014 at 23:27 +0400, Pavel Emelyanov wrote:
> >>>>> ] We need a direct method of getting the pid inside containers.
> >>>>> ] If some issues occurred inside container guest, host user
> >>>>> ] could not know which process is in trouble just by guest pid:
> >>>>> ] the users of container guest only knew the pid inside containers.
> >>>>> ] This will bring obstacle for trouble shooting.
> >>>>>
> >>>>> A new syscall might complicate trouble shooting by admin.
> >>>>
> >>>> Pure syscall -- yes. What if we teach the ps and top utilities to show additional
> >>>> info? I think that would help.
> >>>
> >>> I like the idea with low level non-shell API which can be used by
> >>> utility like ps (or implementation of a new tool to work with complex
> >>> namespace hierarchies).  It should fit for troublesooting.  Then there
> >>> should be no reason to implement two different APIs for observation from
> >>> shell via FS and from applications.
> >>
> >> Maybe we can reuse the existing kcmp() system call? We would have to store
> >> the collected pid values in some hash/tree anyway, and kcmp() provides us
> >> good comparing function for doing this.
> >>
> >> Like we can call kcmp(pid1, pid2, KCMP_PID, nsfd1, nsfd2) which will mean
> >> "Are tasks with pid1 in namespace pointed by nsfd1 and with pid2 in namespace
> >> nsfd2 the same?"
> >>
> >> What do you think?
> > 
> > kcmp() is not needed, just compare inode numbers:
> > 
> >     # ls -il /proc/{43,self}/ns/mnt
> >     208182 lrwxrwxrwx 1 root root 0 мая   29 15:52 /proc/43/ns/mnt -> mnt:[4026531856]
> >     216556 lrwxrwxrwx 1 root root 0 мая   29 15:57 /proc/self/ns/mnt -> mnt:[4026531840]
> 
> But that's for comparing the namespaces, while I'm proposing the kcmp to
> check for PIDs.

Hm, right.

What about the following solution: export global process ID (PID in
init ns) which is visible inside of any namespace.  Then you can compare
numbers regardless in what namespace you are.

-- 
Vasily Kulikov
http://www.openwall.com - bringing security into open computing environments

  parent reply	other threads:[~2014-05-31  6:07 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28 10:24 [PATCH v2] /proc/pid/status: show all sets of pid according to ns Chen Hanxiao
2014-05-28 10:24 ` Chen Hanxiao
     [not found] ` <1401272683-1659-1-git-send-email-chenhanxiao-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>
2014-05-28 12:44   ` Pavel Emelyanov
2014-05-28 12:44     ` Pavel Emelyanov
     [not found]     ` <5385DA19.2060008-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-28 18:28       ` Vasily Kulikov
2014-05-28 18:28         ` Vasily Kulikov
2014-05-28 19:27         ` Pavel Emelyanov
2014-05-28 19:27         ` Pavel Emelyanov
     [not found]           ` <53863889.9080509-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-29  5:59             ` Vasily Kulikov
2014-05-29  5:59               ` Vasily Kulikov
2014-05-29  9:07               ` Pavel Emelyanov
2014-05-29  9:07                 ` Pavel Emelyanov
2014-05-29  9:21                 ` Richard Weinberger
     [not found]                   ` <5386FC0C.9000307-/L3Ra7n9ekc@public.gmane.org>
2014-05-29  9:41                     ` Pavel Emelyanov
2014-05-29  9:41                       ` Pavel Emelyanov
     [not found]                       ` <538700B5.5070601-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-29  9:54                         ` Richard Weinberger
2014-05-29  9:54                           ` Richard Weinberger
     [not found]                           ` <538703D0.7030308-/L3Ra7n9ekc@public.gmane.org>
2014-05-29 10:02                             ` Pavel Emelyanov
2014-05-29 10:02                               ` Pavel Emelyanov
     [not found]                               ` <5387059E.9010105-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-29 10:19                                 ` Richard Weinberger
2014-05-29 10:19                                   ` Richard Weinberger
     [not found]                                   ` <538709A5.60000-/L3Ra7n9ekc@public.gmane.org>
2014-05-29 10:36                                     ` Pavel Emelyanov
2014-05-29 10:36                                       ` Pavel Emelyanov
     [not found]                 ` <5386F8EA.8050501-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-29  9:21                   ` Richard Weinberger
2014-05-29  9:53                   ` chenhanxiao-BthXqXjhjHXQFUHtdCDX3A
2014-05-29 11:12                   ` Vasily Kulikov
2014-05-29 11:12                     ` Vasily Kulikov
2014-05-29 11:31                     ` Pavel Emelyanov
2014-05-29 11:31                       ` Pavel Emelyanov
     [not found]                       ` <53871A92.9000004-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-29 11:59                         ` Vasily Kulikov
2014-05-29 11:59                           ` Vasily Kulikov
2014-05-29 12:53                           ` Pavel Emelyanov
2014-05-29 12:53                             ` Pavel Emelyanov
     [not found]                             ` <53872DAD.1070502-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2014-05-31  6:07                               ` Vasily Kulikov [this message]
2014-05-31  6:07                                 ` Vasily Kulikov
2014-05-31 20:08                                 ` Eric W. Biederman
2014-05-31 20:08                                   ` Eric W. Biederman
2014-05-29  9:53                 ` chenhanxiao
     [not found]                   ` <5871495633F38949900D2BF2DC04883E52A481-ZEd+hNNJ6a5ZYpXjqAkB5jz3u5zwRJJDAzI0kPv9QBlmR6Xm/wNWPw@public.gmane.org>
2014-05-29 10:40                     ` Pavel Emelyanov
2014-05-29 10:40                       ` Pavel Emelyanov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140531060713.GA5315@cachalot \
    --to=segoon-cxoslkxdwojwk0htik3j/w@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=richard.weinberger-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=serge.hallyn-GeWIH/nMZzLQT0dZR+AlfA@public.gmane.org \
    --cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org \
    --cc=xemul-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.