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  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]
Date:	Fri, 22 Jun 2007 12:09:06 +0200
From:	Johannes Berg <>
Cc:	Zhang Rui <>,,
Subject: Re: Fwd: [PATCH] [-mm] ACPI: export ACPI events via netlink

On Thu, 2007-06-21 at 11:47 -0400, jamal wrote:
> 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.

No worries, I was just stating that.

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

Ah, ok, I see now. I was under the impression that groups was always
just a u32.

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

Why do you think that would be hard? It'd basically just mean replacing
the netlink_capable(sock, NL_NONROOT_RECV) calls with a call that
actually tests depending on the group(s) it wants.

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

Yeah, never mind, I thought that the number of groups was limited to 32.

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

Yeah, sounds reasonable, you could ask the controller for which groups
are attached to a family and then get the IDs for those groups by name.


Download attachment "signature.asc" of type "application/pgp-signature" (191 bytes)

Powered by blists - more mailing lists