linux-kernel - Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1ve453lkp.fsf@ebiederm.dsl.xmission.com>
Date:	Sat, 01 Mar 2008 19:29:26 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Pavel Emelyanov <xemul@...nvz.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Alexey Dobriyan <adobriyan@...nvz.org>,
	Linux Netdev List <netdev@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/2] Fix /proc/net in presence of net namespaces

Pavel Emelyanov <xemul@...nvz.org> writes:

> I could use the struct net pointer values (obtained with sprintf(id, "%p", net))
> instead, but exporting internal kernel addresses seemed even uglier.

Agreed.

>> Can you try this approach by capturing a struct pid instead of an id
>> in a new global namespace? 
>
> This is a bad approach. When task, that created the namespace dies, his
> pid is removed from the pidmap and can be reused, so we can get another
> net with the same id.

It takes a little updating of how we use pids.  The easiest method
is to add an extra counter.  So we know when someone besides the hash
chains is using the pid as an id.  However it might make sense to actually
have a net namespace pointer in the pid.

>
> This net's id is not supposed to be used to address any net in the kernel.
> And I see no problems with migration - you can change the net's id safely
> during checkpoint/restart - tasks will always see this one via the /proc/net
> symlink, which is dynamic.

So you are really talking about a hidden id.  There are just enough
ways for something like that to slip out I'm not especially
comfortable with the idea.

I really think we need something clean that we can live with, and be
proud of.  However we implement the enhancement to /proc/net this has
to be maintained for decades.

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/