diff options
author | Evgeniy Polyakov <zbr@ioremap.net> | 2010-02-02 15:58:48 -0800 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2010-02-02 15:58:48 -0800 |
commit | f98bfbd78c37c5946cc53089da32a5f741efdeb7 (patch) | |
tree | 885c756a95f28d4d00868f6eb06ab9c45f11b2e2 /net/key/af_key.c | |
parent | a4c89051c83693e6cd5655b90300ec23a35e04f1 (diff) | |
download | talos-op-linux-f98bfbd78c37c5946cc53089da32a5f741efdeb7.tar.gz talos-op-linux-f98bfbd78c37c5946cc53089da32a5f741efdeb7.zip |
connector: Delete buggy notification code.
On Tue, Feb 02, 2010 at 02:57:14PM -0800, Greg KH (gregkh@suse.de) wrote:
> > There are at least two ways to fix it: using a big cannon and a small
> > one. The former way is to disable notification registration, since it is
> > not used by anyone at all. Second way is to check whether calling
> > process is root and its destination group is -1 (kind of priveledged
> > one) before command is dispatched to workqueue.
>
> Well if no one is using it, removing it makes the most sense, right?
>
> No objection from me, care to make up a patch either way for this?
Getting it is not used, let's drop support for notifications about
(un)registered events from connector.
Another option was to check credentials on receiving, but we can always
restore it without bugs if needed, but genetlink has a wider code base
and none complained, that userspace can not get notification when some
other clients were (un)registered.
Kudos for Sebastian Krahmer <krahmer@suse.de>, who found a bug in the
code.
Signed-off-by: Evgeniy Polyakov <zbr@ioremap.net>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/key/af_key.c')
0 files changed, 0 insertions, 0 deletions