linux-kernel - Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace

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: <545B2DC4.1090005@nod.at>
Date:	Thu, 06 Nov 2014 09:13:56 +0100
From:	Richard Weinberger <richard@....at>
To:	"Chen, Hanxiao" <chenhanxiao@...fujitsu.com>,
	"Serge E. Hallyn" <serge@...lyn.com>
CC:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	Oleg Nesterov <oleg@...hat.com>,
	"containers@...ts.linux-foundation.org" 
	<containers@...ts.linux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mateusz Guzik <mguzik@...hat.com>,
	David Howells <dhowells@...hat.com>
Subject: Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace

Am 06.11.2014 um 06:48 schrieb Chen, Hanxiao:
> 
> 
>> -----Original Message-----
>> From: Richard Weinberger [mailto:richard@....at]
>> Sent: Wednesday, November 05, 2014 8:52 PM
>> To: Serge E. Hallyn
>> Cc: Chen, Hanxiao/陈 晗霄; Eric W. Biederman; Serge Hallyn; Oleg Nesterov;
>> containers@...ts.linux-foundation.org; linux-kernel@...r.kernel.org; Mateusz
>> Guzik; David Howells
>> Subject: Re: [PATCH 1/2v6] procfs: show hierarchy of pid namespace
>>
>> Am 05.11.2014 um 13:41 schrieb Serge E. Hallyn:
>>> Quoting Richard Weinberger (richard@....at):
>>>> Am 05.11.2014 um 11:41 schrieb Chen Hanxiao:
>>>>> We lack of pid hierarchy information, and this will lead to:
>>>>> a) we don't know pids' relationship, who is whose child:
>>>>>    /proc/PID/ns/pid only tell us whether two pids live in different ns
>>>>> b) bring trouble to nested lxc container check/restore/migration
>>>>> c) bring trouble to pid translation between containers;
>>>>>
>>>>> This patch will show the hierarchy of pid namespace
>>>>> by pidns_hierarchy like:
>>>>>
>>>>> [root@...alhost ~]#cat /proc/pidns_hierarchy
>>>>> 18060 18102 1534
>>>>> 18060 18102 1600
>>>>> 1550
>>>>
>>>> Hmm, what about printing the pid hierarchy in the same way as
>> /proc/self/mountinfo
>>>> does with mount namespaces?
>>>> Your current approach is not bad but we should really try to be consistent
>> with existing
>>>> sources of information.
>>>
>>> Good point.  How would you structure it to make it look mor elike mountinfo?
>>> Adding the pidns inode number (in place of a mount sequence number) might be
>>> useful, but it sounds like you have a more concrete idea?
>>
>> Just list <init_PID> <parent_of_init_PID>. This way we have exactly one
>> information record per line and always exactly two columns to parse.
>>
>> e.g.
>> [root@...alhost ~]#cat /proc/pidns_hierarchy
>> 1550 1
>> 18060 1
>> 18102 18060
>> 1534 18102
>> 1600 18102
>>
> But this style lacks of *level* information:

It does not.

> Ex:
> 1->18060->18102->1600->1700
> If we want to check the 1700's level in pid ns
> Style 1:
> 18060 18102 1600 1700
> 
> Style 2:
> 18060 1
> 18102 18060
> 1600 18102
> 1700 1600
> 
> If we had a little more containers,
> Style 2 would not be clear enough.
> 1 line vs $(PID level) line

Any trivial program can find out the level of nesting.

> If there were no more related information to show,
> I think style 1 looks better.

It is not about looking better, it is about parsing and being consistent with existing
interfaces. /proc/pidns_hierarchy will be mostly read by *programs*, not humans.
/proc/ has already too many horrible to parse files, please don't add another one.
This is also why sysfs has the one-value-per-file rule.

If it makes you feel better you can add a third column to the output which indicates
the nesting level (or the distance to the initial pidns) . i.e.
Style 2:
18060 1 1
18102 18060 2
1600 18102 3
1700 1600 4

Thanks,
//richard
--
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/