Page MenuHomeFreeBSD

[net0211] Add new capabilities; restrict what can be done in a jail.

Authored by adrian on Sun, Jul 12, 3:17 AM.


  • Split the MANAGE privilege into MANAGE, SETMAC and CREATE_VAP. + MANAGE is everything but setting the MAC and creating a VAP. + SETMAC is setting the MAC address of the VAP. Typically you wouldn't want the jail to be able to modify this. + CREATE_VAP is to create a new VAP. Again, you don't want to be doing this in a jail, but this DOES stop being able to run some corner cases like Dynamic WDS (DWDS) AP in a jail/vnet. We can figure this bit out later.

This allows me to run wpa_supplicant in a jail after transferring
a STA VAP into it. I unfortunately can't currently set the wlan
debugging inside the jail; that would be super useful!

Note that running wpa_supplicant in a jail requires lo0 to be up
and have an IPv4 address otherwise it doesn't get the routing
socket message size - it uses NET_RT_DUMP to do so. That should
be fixed in a later change.

Test Plan
  • STA mode, AR9380, in vnet/jails.

Diff Detail

rS FreeBSD src repository
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

adrian created this revision.Sun, Jul 12, 3:17 AM
adrian requested review of this revision.Sun, Jul 12, 3:17 AM
bz added a subscriber: bz.Mon, Jul 13, 8:26 AM

About the commit message.

"capabilities" are something different in our kernel.
I'd really try to stick with the term "privileges" in the description.
The entire "note that ...lo0 .. " has nothing to do with this change at all so shouldn't be there.

3069 ↗(On Diff #74342)

We normally do not leave comments here for any of these. Sadly we don't have a good man page apart from a wlan one maybe to document this. It'll be in the commit message at least, which is good.

252 ↗(On Diff #74342)

This seems unrelated noise and should not be part of that commit.

356 ↗(On Diff #74342)

it is VAP_* for the others, can this one also be VAP_CREATE?

bz requested changes to this revision.Mon, Jul 13, 8:27 AM
This revision now requires changes to proceed.Mon, Jul 13, 8:27 AM
emaste added a subscriber: emaste.Mon, Jul 13, 1:48 PM
adrian added inline comments.Sun, Jul 19, 5:53 AM
252 ↗(On Diff #74342)

Yeah, this is a left-over from other work in this tree.

356 ↗(On Diff #74342)

The others operate on vaps, this one doesn't technically operate ON a vap, it ends up making one. I didn't know how else to express that clearly.

adrian updated this revision to Diff 74636.Sun, Jul 19, 5:54 AM

Take on comments from bz

adrian marked 2 inline comments as done.Sun, Jul 19, 5:55 AM

Updated from feedback

bz accepted this revision.Sun, Jul 19, 1:50 PM
This revision is now accepted and ready to land.Sun, Jul 19, 1:50 PM

I think this broke the build on r363327 with if_an.

To unbreak, I opened D25723.

imp added a comment.Sun, Jul 19, 6:16 PM

I think this broke the build on r363327 with if_an.

Maybe we should just retire wi and an? They are no longer relevant.

In D25630#569426, @imp wrote:

I think this broke the build on r363327 with if_an.

Maybe we should just retire wi and an? They are no longer relevant.

amusingly I'm thinking of resurrecting wi's 802.3 path because - get this - the 11ac/11ax hardware is trending towards 802.3 offloaded data paths, and it's SUPER EASY to test that with wi(4).

Our wi(4) was just rewritten to use the raw mode for WPA support but didn't include the firmware reflashing bits.

Lemme think about it. I don't even know if I have an(4) hardware anymore.