sysfs vs. d80211 configuration

Hey,

In my seemingly never-ending quest to actually use the d80211 stack for something useful I just wanted to write a small setuid tool that:
* creates and opens a new monitor interface
* drops priviledges
* ... does things with received frames ... (not interesting for this discussion)
* removes new monitor interface

So I figured I'd just keep an fd open to /sys/class/net/mymonitorinterface/remove_iface to which I could write the interfaces name after I was done with it. However, when writing to that fd I got -EACCESS because it checks for CAP_NET_ADMIN.

That seems to make sense. However, it also means that I can simply not write the tool that way, it can't drop priviledges. Of course it could re-exec itself with a special parameter to tell it to remove the interface, but that'd allow anyone to use it to remove any interface. Not good either.

Hence, it seems that in order to properly solve this I should simply add a new sysfs "remove" property for each d80211 virtual interface that triggers a removal whenever anything is written to it. And it should not have a check for CAP_NET_ADMIN so I can use it after dropping priviledges. Sounds great, right? So why isn't there a patch attached to this mail?

Well, it isn't too great. See, if you think about it again, removing an interface *should* require CAP_NET_ADMIN. But if I want to enable above use-case, then I have to check for CAP_NET_ADMIN when *opening* the sysfs attribute file, not writing to it. But that doesn't seem possible to do. Hence, I lose capability granularity. But it seems that sysfs doesn't allow me to do that. [Nor does a configuration system via netlink. hmm]

Do I lose? Or put from my kernel developer perspective: should we even be enabling such a use?

johannes

Why not have the tool create a monitor interface, open it, and fork; the child drops privileges and does the reading, and the parent wait(2)s for the child and removes the interface once it has collected the child?

Alexey

Kismet achieves this nearly the same way -- It keeps a root process for channel control, and talks over IPC to a nonpriv process. When it's done, it sends the shutdown command to the root process and restores the interface settings (or removes monitor interfaces, etc).

If you set up all your interfaces before the fork you can keep the IPC very simple.

-m

Mike Kershaw/Dragorn <[email protected]>
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

Good point, that'll work. Then again, I want this to run on really tiny architectures and I'm thinking some of them might not have fork(), just vfork(). Hmm.

johannes

Then again, on those platforms there is no real benefit from dropping privs, is there. Heh.

johannes