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
| ||
|
Date: Mon, 09 May 2016 09:30:45 +0200 From: Johannes Berg <johannes@...solutions.net> To: Martin Willi <martin@...ongswan.org> Cc: linux-wireless@...r.kernel.org, netdev@...r.kernel.org Subject: Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces On Wed, 2016-05-04 at 10:33 +0200, Martin Willi wrote: > > This changes today's default behaviour of moving the wiphys to the > > default namespace. Did you intend to destroy them based on the > > netgroup, i.e. based on the namespace that created them? Actually, > > maybe they should move back to the namespace that created them, if > > the namespace they are in is destroyed? But that's difficult, I > > don't > > mind this behaviour, but I'm not sure it's what we want by default > > for radios created in the init_net. > With the proposed approach I destroy all radios if the owning > namespace gets deleted, because we probably don't want them landing > in init_net if they are created from a (unprivileged) userns process. I agree they shouldn't land in init_net. > I think this is what other "virtual" interfaces do (gre tunnels, veth > etc.). If we think of hwsim radios as such a "virtual" device, that > makes IMO sense to delete them. Ok, I have no idea what happens there. > If we want to keep the existing behavior, we could move radios > belonging to the init_net-associated netgroup back to init_net, that > shouldn't be too difficult. > > Moving the radio back to the creators namespace would be the most > consistent behavior, so I'll check how difficult such a reverse > lookup is. We then would delete the radio only if it is in the > creators namespace, or if the creators namespace is gone. Does that > make sense? It does make sense, but it does also feel a bit complicated. Perhaps just special-case the init_net case for consistency with the existing behaviour, and reserve netgroup 0 for that so we can easily check for it? johannes
Powered by blists - more mailing lists