netdev - Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1182440840.5017.40.camel@localhost>
Date:	Thu, 21 Jun 2007 11:47:20 -0400
From:	jamal <hadi@...erus.ca>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Zhang Rui <rui.zhang@...el.com>, netdev@...r.kernel.org,
	lenb@...nel.org
Subject: Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

On Wed, 2007-20-06 at 13:25 +0200, Johannes Berg wrote:

> Ok. That's definitely a bug in nl80211 as we have it in development
> right now. 

Sorry, have never looked at that code.

> Btw, what happens if the group id gets larger than 31?

You can use setsockopt to set the multicast groups. What you cant do
with that is subscribe to many groups in one shot.
The call in iproute2 hasnt reflected this reality yet.

> I'd really like to be able to reserve multicast groups with special
> semantics too, especially I might want to permit/deny non-CAP_NET_ADMIN
> users from binding specific multicast groups. That isn't actually
> possible with netlink nor genetlink right now afaict.

This would be hard - but doable via SELinux interface. I think you
should be able to extend your tool to make calls to that interface.

> If we register multiple IDs then we'll end up filling up the generic
> netlink family space really soon. 

Theres a huge number of these groups; and not just that, but considering
that some genetlink users may not be interested in such multicast
groups, it is quiet usable to have many groups as long as we avoid
conflict.

> I was under the impression that
> generic netlink was basically open-ended because the family is a large
> enough number, but with this arbitrary limit on multicast groups that's
> really not true and we might run out of multicast groups fairly soon
> since most users of generic netlink will want at least one...
> 

The multicast issue wasnt well-attacked. We have a group magically
assigned to a user based on their allocated id. It should be feasible
to add an API to the kernel for registering for many groups and allow
user space to discover these groups before registering. Maybe thats
the path to proceed to.

cheers,
jamal

-
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