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

On Mon, 14 Aug 2006, Johannes Berg wrote:

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.

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

On Mon, Aug 14, 2006 at 11:05:15PM +0000, Alexey Toptygin wrote:

On Mon, 14 Aug 2006, Johannes Berg wrote:

quoted

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.

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?

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 [off-list ref]
GPG Fingerprint: 3546 89DF 3C9D ED80 3381  A661 D7B2 8822 738B BDB1

Alexey Toptygin wrote:

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?

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

Johannes Berg wrote:

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.

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

johannes