netdev - Re: RFC: netfilter: nf_conntrack: add support for "conntrack zones"

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]

Date:	Tue, 23 Feb 2010 17:32:07 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Matt Helsley <matthltc@...ibm.com>
Cc:	hadi@...erus.ca, Linux Netdev List <netdev@...r.kernel.org>,
	containers@...ts.linux-foundation.org,
	Netfilter Development Mailinglist 
	<netfilter-devel@...r.kernel.org>,
	Ben Greear <greearb@...delatech.com>,
	Daniel Lezcano <dlezcano@...ibm.com>
Subject: Re: RFC: netfilter: nf_conntrack: add support for "conntrack zones"

Matt Helsley <matthltc@...ibm.com> writes:

> On Tue, Feb 23, 2010 at 12:00:55PM -0800, Eric W. Biederman wrote:
>> jamal <hadi@...erus.ca> writes:
>> 
>> > Added Daniel to the discussion..
>> >
>> > On Tue, 2010-02-23 at 06:07 -0800, Eric W. Biederman wrote:
>> >> jamal <hadi@...erus.ca> writes:
>> >
>> >> > Does the point after sys_setns(fd) allow me to do io inside
>> >> > ns <name>? Can i do open() and get a fd from ns <name>?
>> >> 
>> >> Yes.  My intention is that current->nsproxy->net_ns be changed.
>> >> We can already change it in unshare so this is feasible.
>> >
>> > I like it if it makes it as easy as it sounds;-> With lxc,
>> > i essentially have to create a proxy process inside the
>> > namespace that i use unix domain to open fds inside the ns.
>> > Do i still need that?
>> 
>> That point of the mount to hold a persistent reference to the
>> namespace without using a process.
>
> I think technicaly it's still held using processes, only now it's
> much more indirect:
>
> netns <- mount <- mount namespace(s) <- process(es)

True. The practical difference is that it doesn't require a dedicated
process which is a big improvement operationally.

> Using a mount requires keeping names for the namespaces themselves
> in the kernel which is a problem we've largely avoided so far.
> The nscgroup is an example of the messes that creates, I think. And it
> further complicates c/r -- we'd need to checkpoint and recreate the
> names of the namespaces too. So we'll need a namespace for the names of
> the namespaces to make restart reliable won't we? Makes my head spin...

This is strictly different.  It may require a bit of extra support from
checkpoint/restart because it introduces some more user visible objects
but the names themselves are nothing special.  The name that userspace
sees and deals with is the name of the mount point.  No new namespaces
are required.

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html