Re: [PATCH net-2.6.26] netlink: make socket filters work on netlink

[jamal <hadi@cyberus.ca>]

On Wed, 2008-02-04 at 12:00 +0200, Patrick McHardy wrote:

> No, in the case of events its supposed to be set to the pid of the
> socket that caused the event. Check out qdisc_notify() or rtmsg_ifa()
> for example.

nod - however, there is inconsistency;
for example if rtmsg_ifa() was in the code path of something invoked by
ioctl, the pid of the event will be 0. Alexey almost chewed my head off
when i tried to change that. His (valid) explanation was, if iirc:
a) that the pid belonged to the source - and 0 means "kernel". 
b) The pid could also be some negative number (even in qdisc_notify) if
you have multiple netlink sockets in one process (resolvable if you
getname())
c) what happens when processid goes to > 32-bit?

> nlmsg_seq is already used by userspace to match responses to requests,
> so that probably wouldn't work very well.

True, and thats what made me suggest earlier that if i had two sockets
in my app, one listening and the other sending (the way quagga does for
example), and that the app has a setting which says "all my netlink
messages to the kernel would have sequence 0x1234" - then the listening
socket could be told to set bpf to filter out any events with sequence
0x1234. This overcomes all of #a, #b and #c above but i admit it is
equally weak as using pids because it relies on the fact that only one
app is targeting something in the kernel with sequence 0x1234. You could
do it if you owned the box.
As one step further - route messages "proto" field on the other hand
overcomes that challenge of multiple applications ambiguity. of course
this has other challenges as well (ex: several apps claiming to be zebra
or if you intentionaly want to run multiple quaggas for VRs but wanted
to distinguish who added the route).

cheers,
jamal