linux-kernel - Re: [PATCH 1/2] proc: Show ns-based inode numbers for /proc/pid/ns/* files

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:	Sat, 26 May 2012 09:14:33 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Pavel Emelyanov <xemul@...allels.com>
Cc:	Daniel Lezcano <dlezcano@...ibm.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"Serge E. Hallyn" <serge@...lyn.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 1/2] proc: Show ns-based inode numbers for /proc/pid/ns/* files

Pavel Emelyanov <xemul@...allels.com> writes:

> On 05/11/2012 09:07 PM, Eric W. Biederman wrote:
>> Pavel Emelyanov <xemul@...allels.com> writes:
>> 
>>> Some time ago we tried to expose kernel object IDs to the user space to
>>> let it possible to detect shared mm, fs, etc. The namespaces' IDs were
>>> included in this set and Eric proposed, that we'd better expose the ID
>>> in the stat's st_ino field.
>> 
>> A quick question.  With kcmp you have something that is at least in
>> principle usable for checkpoint restart.
>
> Not only in principle. We do use it already ;)
>
>> Are wanting this for checkpoint restart or something else?
>
> For me -- checkpoint restart only. I'm perfectly fine with checking 
> namespaces sharing with kcmp syscall, but you proposed to show ns ID
> in proc inode.

I still think it makes a lot of sense to use stable inode number for
each filesystem.  I am travelling at the moment and I can't find a copy
of your original patch I plan to be home by the end of the week, so
I will have to dig it up then.

>From what I remember the something seemed off with your inode
generation.  From my quick glance earlier it looked a bit wrong.  My
earlier attempt was to essentially export
fs/proc/generic.c:get_inode_number and just have a field in the various
namespaces to store that number.  Plus a method to read that field.
Your patch from my memory seemd to be doing something more than that.

My original plan was to finish setns support before moving on to
stable inode numbers.  But that didn't work out.  I will reevaluate
as I sort out what I need to get done for the next merge window.

I was quite disappointed with the lack of review my mount namespace
patch got from Viro and the other vfs people.  So I think I will
probably have to host a tree myself.  At which point stable
inode support won't be hard. 

It would be good to have kcmp support for namespaces as well as having
an id.  I think the merged functionality in proc_ns_operations is
probably enough for kcmp as is.

Until I have had a few days to play after the merge window closes and
I can't say what I will really be doing but I do want to get this
chunk of work finished, it is definitely time.

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/