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

[jamal <hadi@cyberus.ca>]

On Wed, 2008-02-04 at 14:45 +0200, Patrick McHardy wrote:

> Mhh .. we could use a magic nlmsg_pid value (just like zero)
> to indicate it was done on behalf of a process using ioctls or
> some other, non-netlink means. 

In my experience attempting to write user space apps which worry about
whodunnit and filtering in user space (essentially solving similar
problem to what Stephen is attempting to), this non-nl paths have been
the most headache. Every book written on linux network config
demonstrates ifconfig and route utilities. Of course you could put
restrictions with caveats like "my app works only if you used ip or used
ifconfig version 3 which uses netlink" - but that puts a damp in the
whole concept.

> I'm wondering how useful this
> (or any other "whodunit" identifier) would be for filtering
> though, I think you're usually more interested in certain
> objects than certain processes, like all routes to 192.168.0.0/16,
> no matter who changes them.

I think both are of interest.
Historically in routes for example, the interest would be apps/processes
(not direct mapping to processids) that are of interest (eg a route
added by OSPF vs one added by RIP etc). Filtering is done in user space
so you dont repropagate routes added by the "OSPF process" to RIP if
policy says so etc.
That of course has evolved to application name (gated vs zebra vs bird
etc) which implements all of OSPF/RIP/BGP etc and can keep track of
things. Theres further evolution which desires to run multiple instances
of quagga on the same machine etc.
I dont think the processid is the right thing, but some 32 bit id which
maps to a name would be useful or even a static field defined in some
header file. The name serving could be out of the kernel for simplicity
if the process dies and is re-incarnated it knows what to read(some of
these ideas are already in genetlink).

> Unfortunately we can't add a new field to the existing headers
> without breaking things, so anything new would likely be subsystem
> specific.

Agreed, it is a bit too late to change netlink without breaking apps
(and reason i was suggesting i was going to add it to actions/cls).
Essentially even in subsystem specifics it would be an attribute
(transported via TLV).

cheers,
jamal