public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Cc: netdev <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-wireless
	<linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: wireless vs. network namespaces
Date: Fri, 14 Sep 2007 09:31:09 -0600	[thread overview]
Message-ID: <m1bqc52ria.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <1189763513.3974.26.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org> (Johannes Berg's message of "Fri, 14 Sep 2007 11:51:53 +0200")

Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org> writes:

> Now that the network namespace work is in net-2.6.24, I'm wondering how
> wireless will be handling this. Is there any benefit at all to a
> wireless device supporting network namespaces?

Good question.  Network namespaces are designed as a general tool
so if we can support network namespaces in the wireless stack without
killing ourselves there should be value in it.

> Should we, for now, set the new NETIF_F_NETNS_LOCAL flag for all
> mac80211 devices?
>
> If we do want to support moving, then we'll have to make cfg80211
> (preferably, though mac80211 might be easier at first) migrate *all*
> virtual interfaces associated with the same wiphy because otherwise
> we'll get into trouble when moving one virtual interface and then
> somebody in the other namespace changes its operating channel.

Ok.  This appears at least to be an atomicity issue and possibly more.

I don't currently understand the way the wireless interfaces interact
well enough to make a judgement call.

There are two basic usage models I can currently think of.
1) Super chroot.  Where a group of processes has distinct mount,
   network, uts, ipc, and pid namespaces.  So in this case on the
   inside we will only see processes that only belong to our own
   network namespace.  So in this scenario you get whatever the person
   who sets up the environment gives you.

   If one of the network devices only allows access to a subset of
   the wireless networking  (say just sending packets but not
   controlling the radio aspects) I can see and advantage in only
   having that device in the restricted network namespace.

2) Advanced routing.  Where someone is doing some weird thing like 
   testing sending packets and receiving them on the same machine.

Currently creation of a network namespace requires CAP_SYS_ADMIN
and for device movement we only require CAP_NET_ADMIN.  So these are
all privileged operations.  So the scenario you are concerned about
may just be a "don't do that then".

If this doesn't give you enough information to make the call can
you describe for me how the separation of wireless network interfaces
work?

Eric

  parent reply	other threads:[~2007-09-14 15:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-14  9:51 wireless vs. network namespaces Johannes Berg
     [not found] ` <1189763513.3974.26.camel-YfaajirXv214zXjbi5bjpg@public.gmane.org>
2007-09-14 15:31   ` Eric W. Biederman [this message]
     [not found]     ` <m1bqc52ria.fsf-T1Yj925okcoyDheHMi7gv2pdwda3JcWeAL8bYrjMMd8@public.gmane.org>
2007-09-14 17:59       ` Johannes Berg

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=m1bqc52ria.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org \
    --cc=linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.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