linux-kernel - RE: [PATCH] ns: introduce getnspid syscall

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5871495633F38949900D2BF2DC04883E548592@G08CNEXMBPEKD02.g08.fujitsu.local>
Date:	Wed, 18 Jun 2014 10:03:40 +0000
From:	"chenhanxiao@...fujitsu.com" <chenhanxiao@...fujitsu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
CC:	"containers@...ts.linux-foundation.org" 
	<containers@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	David Howells <dhowells@...hat.com>,
	"Richard Weinberger" <richard.weinberger@...il.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Vasiliy Kulikov <segooon@...il.com>,
	"Gotou, Yasunori" <y-goto@...fujitsu.com>,
	Linux API <linux-api@...r.kernel.org>,
	"Michael Kerrisk-manpages" <mtk.manpages@...il.com>
Subject: RE: [PATCH] ns: introduce getnspid syscall

Hi,

> -----Original Message-----
> From: Eric W. Biederman [mailto:ebiederm@...ssion.com]
> Sent: Wednesday, June 18, 2014 9:31 AM
> To: Chen, Hanxiao/陈 晗霄
> Cc: containers@...ts.linux-foundation.org; linux-kernel@...r.kernel.org;
> Andrew Morton; Serge Hallyn; Daniel P. Berrange; Oleg Nesterov; Al Viro; David
> Howells; Richard Weinberger; Pavel Emelyanov; Vasiliy Kulikov; Gotou, Yasunori/
> 五�u 康文; Linux API; Michael Kerrisk-manpages
> Subject: Re: [PATCH] ns: introduce getnspid syscall
> 
> Chen Hanxiao <chenhanxiao@...fujitsu.com> writes:
> 
> > 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.
> 
> There is also some ongoing work to export this information via a proc
> file which seems more appropriate for solving your problem.  Certainly
> for debugging something easily human discoverable is needed.
> 

Do you mean this patch:
/proc/pid/status: show all sets of pid according to ns
https://lkml.org/lkml/2014/5/26/145

But no new comments on this patch,
Pavel suggested that a syscall should be a good choice.
Do we should continue this kind of work?

> > int getnspid(pid_t pid, int fd1, int fd2, int pidtype);
> 
> The pidtype is nonsense.  The translation of a pid does not depend upon
> type.  Using that kind of nonsense will lead you and others into confusion.
> 

I see.

> > pid: the pid number need to be translated.
> >
> > fd: a file descriptor referring to one of
> >     the namespace entries in a /proc/[pid]/ns/pid.
> >     fd1 for destination ns(ns1), where the pid came from.
> >     fd2 for reference ns(ns2), while fd2 = -2 means for current ns.
> >
> > pidtype: 0 PIDTYPE_PID; 1 PIDTYPE_PGID; 2 PIDTYPE_SID.
> >
> > return value:
> >     >0: translated pid in ns1(fd1) seen from ns2(fd2).
> >     <0: on failure.
> 
> Elsewhere we use 0 on pid translation failure.  Why be different here?
> 

It should be <=0. And <0 means some other failures.

> Eric
> 
> 
> > Signed-off-by: Chen Hanxiao <chenhanxiao@...fujitsu.com>
> > +
> > +	rcu_read_lock();
> > +	task = find_task_by_pid_ns(pid, ns1);
> 
> The functions you want to be using here are:
> find_pid_ns and pid_nr_ns.
> 

Thanks for your hint.

- Chen