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

Message-ID: <87a9b95icy.fsf@x220.int.ebiederm.org>
Date:	Fri, 25 Apr 2014 12:17:33 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Chen Hanxiao <chenhanxiao@...fujitsu.com>,
	containers@...ts.linux-foundation.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

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?

>> 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 ...

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/