netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: kaber@trash.net, netdev@vger.kernel.org, hadi@cyberus.ca,
	shemminger@linux-foundation.org, greearb@candelatech.com,
	jeff@garzik.org, yoshfuji@linux-ipv6.org,
	containers@lists.osdl.org, torvalds@linux-foundation.org,
	akpm@linux-foundation.org
Subject: Re: [RFD] L2 Network namespace infrastructure
Date: Sun, 24 Jun 2007 06:58:54 -0600	[thread overview]
Message-ID: <m1zm2p7bld.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20070623.224511.00323567.davem@davemloft.net> (David Miller's message of "Sat, 23 Jun 2007 22:45:11 -0700 (PDT)")

David Miller <davem@davemloft.net> writes:

> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Sat, 23 Jun 2007 15:41:16 -0600
>
>> If you want the argument to compile out.  That is not a problem at all.
>> I dropped that part from my patch because it makes infrastructure more
>> complicated and there appeared to be no gain.  However having a type
>> that you can pass that the compiler can optimize away is not a
>> problem.  Basically you just make the argument:
>> 
>> typedef struct {} you_can_compile_me_out;  /* when you don't want it. */
>> typedef void * you_can_compile_me_out;     /* when you do want it. */
>> 
>> And gcc will generate no code to pass the argument when you compile
>> it out.
>
> I don't want to have to see or be aware of the types or the
> fact that we support namespaces when I work on the networking
> code.
>
> This is why I like the security layer in the kernel we have,
> I can disable it and it's completely not there.  And I can
> be completely ignorant of it's existence when I work on the
> networking stack.

That is a mostly reasonable objection.  I certainly see minimal
impact to people working on the code long term is an important goal.

My impression of the current linux security subsystem is a non-flexible
brittle iptables that works between processes.  I'm rather jaded in
that regard because I have fixed several things and broken the security
subsystem, and people yell.  So I'm not certain if it is good for anything
or if we can actually ignore it right now.  However for most of networking
we can ignore it.

What makes namespaces interesting to me is that they enable us to do things
that we can't do with linux today.  Sorry you seem to have a security
mono-focus so this bears repeating.



I'm not trying to hide network namespaces because I think that is
potentially a much more serious maintenance issue.

During the merge and enabling of this we have to audit everything or
not be responsible programmers.  So that is going to be slightly
intrusive.

I am convinced I can keep network namespaces something that is so
trivial and obvious to get right you won't have to pay attention
to them.

Mostly it isn't the core paths in the network that are a challenge to
work with but the little out of the way paths that don't take a
network device or a socket, and things like the initialization code
which is almost never touched. 


I don't actually thing the core fast paths of the network stack even
make namespaces visible.  I will go back an reexamine that.


You are asking for something much more challenging though.  You are
asking for absolutely no foot-print.  Something that is a completely a
side-car.  Given the thousands of global variables in the networking
code I don't know if that is possible to implement.

Eric


  reply	other threads:[~2007-06-24 13:04 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-22 19:39 [RFD] L2 Network namespace infrastructure Eric W. Biederman
2007-06-22 21:22 ` [PATCH] net: Basic network " Eric W. Biederman
2007-06-23 10:40 ` [RFD] L2 Network " Patrick McHardy
2007-06-23 15:20   ` Ben Greear
2007-06-23 17:26     ` Eric W. Biederman
2007-06-23 20:09       ` Ben Greear
2007-06-23 20:39         ` Eric W. Biederman
2007-06-23 20:44           ` Ben Greear
2007-06-23 17:26     ` Stephen Hemminger
2007-06-23 17:55       ` Eric W. Biederman
2007-06-23 20:03       ` Ben Greear
2007-06-27 14:41     ` [Devel] " Kirill Korotaev
2007-06-23 17:19   ` Eric W. Biederman
2007-06-23 18:00     ` Patrick McHardy
2007-06-23 19:08       ` Eric W. Biederman
2007-06-23 20:19     ` Carl-Daniel Hailfinger
2007-06-23 20:31       ` Eric W. Biederman
2007-06-23 20:57     ` David Miller
2007-06-23 21:22       ` Benny Amorsen
2007-06-24  5:39         ` David Miller
2007-06-23 21:41       ` Eric W. Biederman
2007-06-24  5:45         ` David Miller
2007-06-24 12:58           ` Eric W. Biederman [this message]
2007-06-25  2:39             ` David Miller
2007-06-26 15:32               ` Eric W. Biederman
2007-06-23 22:15       ` Jeff Garzik
2007-06-23 22:56         ` Eric W. Biederman
2007-06-24  1:28           ` Jeff Garzik
2007-06-25 15:23             ` Serge E. Hallyn
2007-06-27 15:38             ` [Devel] " Kirill Korotaev
2007-06-24  5:48           ` David Miller
2007-06-24 10:25             ` Benny Amorsen
2007-06-24 12:38             ` Eric W. Biederman
2007-06-25 15:11       ` Serge E. Hallyn
2007-06-28 14:53     ` Kirill Korotaev
2007-06-27 14:39   ` [Devel] " Kirill Korotaev
2007-06-27 14:45     ` Patrick McHardy
2007-06-27 14:56     ` Ben Greear
2007-06-28 13:12       ` Kirill Korotaev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1zm2p7bld.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=containers@lists.osdl.org \
    --cc=davem@davemloft.net \
    --cc=greearb@candelatech.com \
    --cc=hadi@cyberus.ca \
    --cc=jeff@garzik.org \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.org \
    --cc=torvalds@linux-foundation.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).