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: <5871495633F38949900D2BF2DC04883E5483C2@G08CNEXMBPEKD02.g08.fujitsu.local>
Date:	Wed, 18 Jun 2014 08:28:30 +0000
From:	"chenhanxiao@...fujitsu.com" <chenhanxiao@...fujitsu.com>
To:	Pavel Emelyanov <xemul@...allels.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>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	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>,
	Vasiliy Kulikov <segooon@...il.com>,
	"Gotou, Yasunori" <y-goto@...fujitsu.com>
Subject: RE: [PATCH] ns: introduce getnspid syscall



> -----Original Message-----
> From: Pavel Emelyanov [mailto:xemul@...allels.com]
> Sent: Tuesday, June 17, 2014 8:13 PM
> To: Chen, Hanxiao/陈 晗霄
> Cc: containers@...ts.linux-foundation.org; linux-kernel@...r.kernel.org;
> Andrew Morton; Eric W. Biederman; Serge Hallyn; Daniel P. Berrange; Oleg Nesterov;
> Al Viro; David Howells; Richard Weinberger; Vasiliy Kulikov; Gotou, Yasunori/
> 五�u 康文
> Subject: Re: [PATCH] ns: introduce getnspid syscall
> 
> On 06/17/2014 02:21 PM, Chen Hanxiao 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.
> >
> > int getnspid(pid_t pid, int fd1, int fd2, int pidtype);
> >
> > 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.
> >
> > +	}
> > +
> > +	switch (pidtype) {
> 
> There's no need in switch, the __task_pid_nr_ns() accepts
> the type argument.
> 

Yes, I think we still have that kind of functions, so I used them...

> > +	case PIDTYPE_PID:
> > +		ret = task_pid_nr_ns(task, ns2);
> 
> But this is not correct. If task doesn't live in ns2, but ns2
> just has the ns->level small enough, then the wrong pid value
> would be reported.
> 

Right, we should check whether the task belonged to that namespace firstly.

Thanks,
- Chen

> > +		break;
> > +	case PIDTYPE_PGID:
> > +		ret = task_pgrp_nr_ns(task, ns2);
> > +		break;
> > +	case PIDTYPE_SID:
> > +		ret = task_session_nr_ns(task, ns2);
> > +		break;
> > +	default:
> > +		ret = -EINVAL;
> > +	}
> > +	ret = (ret == 0) ? -ESRCH : ret;
> > +
> > +out:
> > +	fput(file1);
> > +	if (file2)
> > +		fput(file2);
> > +	return ret;
> > +}
> > +
> >  int __init nsproxy_cache_init(void)
> >  {
> >  	nsproxy_cachep = KMEM_CACHE(nsproxy, SLAB_PANIC);
> >
>