linux-kernel - RE: [Resend][PATCH] ns,proc: introduce pid_in

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] [day] [month] [year] [list]

Date:	Tue, 13 May 2014 09:15:55 +0000
From:	"chenhanxiao@...fujitsu.com" <chenhanxiao@...fujitsu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Oleg Nesterov <oleg@...hat.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>,
	Al Viro <viro@...iv.linux.org.uk>,
	David Howells <dhowells@...hat.com>
Subject: RE: [Resend][PATCH] ns,proc: introduce pid_in_ns



> -----Original Message-----
> From: Eric W. Biederman [mailto:ebiederm@...ssion.com]
> Sent: Saturday, April 26, 2014 3:18 AM
> To: Oleg Nesterov
> Cc: Chen, Hanxiao/陈 晗霄; containers@...ts.linux-foundation.org;
> linux-kernel@...r.kernel.org; Andrew Morton; Serge Hallyn; Daniel P. Berrange;
> Al Viro; David Howells
> Subject: Re: [Resend][PATCH] ns,proc: introduce pid_in_ns
> 
> Oleg Nesterov <oleg@...hat.com> writes:
> 
> > On 04/25, Chen Hanxiao wrote:
> >>
> >> We lacked of convenient method of getting the pid inside containers.
> 
> Are unix domain sockets not convinient?
> 

It's a very good method, but not so directly for just pid translation.

> >> 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.
> >>
> >> This patch introduces pid_in_ns:
> >> If one process is in init_pid_ns, /proc/PID/pid_in_ns
> >> equals to /proc/PID;
> >> if one process is in pidns, /proc/PID/pid_in_ns
> >> will tell the pid inside containers;
> >> if pidns is nested, it depends on which pidns are you in.
> >
> > Yes another /proc/pid/ file...
> >
> > Perhaps it would be better to change /proc/pid/status["Pid:"] to report the
> > list of pid_nr's, from its namespace up to the observer's namespace. The same
> > for "Tgid:".
> >
> > (Hmm. And why "Ngid:" was inserted between tid and tgid ?)
> 
> Add to that Ngid has a completely hosed implementation.  It is a pid
> stored in a pid_t, not a struct pid *.  Sigh.
> 
> I am getting more and more tempted to obliterate task->pid.  It just
> encourages bad code.
> 
> >> +int proc_pid_in_ns(struct seq_file *m, struct pid_namespace *ns,
> >> +			struct pid *pid, struct task_struct *task)
> >> +{
> >> +	pid_t pid_in_ns;
> >> +	unsigned int level;
> >> +
> >> +	level = pid->level;
> >> +	pid_in_ns = task_pid_nr_ns(task, pid->numbers[level].ns);
> >
> > This looks overcomplicated or I missed something?
> 
> I do think if we care we need to print the entire set of pids.
> I don't know if /proc/pid/status is the proper place but ...
> 

Let's print the entire set of pids in /proc/pid/status.

> Eric

Thanks for the comments.
v2 will come soon.

- Chen