[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47F38002.70005@trash.net>
Date: Wed, 02 Apr 2008 14:45:54 +0200
From: Patrick McHardy <kaber@...sh.net>
To: hadi@...erus.ca
CC: Thomas Graf <tgraf@...g.ch>, David Miller <davem@...emloft.net>,
shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-2.6.26] netlink: make socket filters work on netlink
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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists