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

[Patrick McHardy <kaber@trash.net>]

jamal wrote:
> On Wed, 2008-02-04 at 14:09 +0200, Patrick McHardy wrote:
> 
>> Yes, but it was the use of current->pid that was wrong.
> 
> There are many many apps out there which still use ioctls - hence the
> ambiguity of "is it the kernel that generated the command that caused
> the event or was it merely a proxy for some app". 
> You need to resolve that. 

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. 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.

>> If one of those calls are in a path invoked through netlink
>> it should set nlmsg_pid.
> 
> Nod - I think thats mostly taken care of; havent looked lately. I know
> Alexey didnt object to any patches i submitted that did change how
> nlmsg_pid was set on events to match this thought and I cant think of a
> reason it would violate any netlink ettiquette. 
> 
> Note, I find the whoddunit field (not the pid) to be also useful for
> aesthetics and debugging other than for the non-ambiguity in the
> filtering.

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