No special workarounds in my package that I'm aware of! My guess would
be that it's inconsistent between netlink families. I've only really
played with genetlink and rtnetlink.
- Matt
On 02/22/2017 05:14 PM, Steven Hartland wrote:
Hmm fails with EPERM when we try to listen for CN_IDX_PROC I guess
that may be a special case given what it is.
Be interested to know if your module avoids this issue somehow?
On 22/02/2017 21:17, Matt Layher wrote:
> 1. "Only processes with an effective UID of 0 or the CAP_NET_ADMIN capability
may send or listen to a netlink multicast group."
This appears not to be true, at least in the case of rtnetlink and
listening to multicast notifications for link additions and removals.
https://play.golang.org/p/dn3-549-Ay
First terminal:
$ whoami
matt
$ go build
$ getcap ./nlmcast
$ ./nlmcast
Second terminal:
$ sudo ip link add type nlmon
$ sudo ip link del dev nlmon0
Back to first terminal (./nlmcast still running):
2017/02/22 16:13:46 received 1 messages
2017/02/22 16:13:50 received 1 messages
> 2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an
effective UID of 0."
Yep, this is documented in my package:
https://godoc.org/github.com/mdlayher/netlink#HeaderFlags
I had read in some header, I think, that NLM_F_ATOMIC "may be
obsolete". I haven't ever tried it. I should look into it. I'll also
note this case in my post.
- Matt
On Wednesday, February 22, 2017 at 3:45:24 PM UTC-5, Steven Hartland
wrote:
It's required for read only in some situations too, for example
we use it here to listen for process exit codes.
http://man7.org/linux/man-pages/man7/netlink.7.html
<http://man7.org/linux/man-pages/man7/netlink.7.html>
Mentions two separate cases:
1. "Only processes with an effective UID of 0 or the
CAP_NET_ADMIN capability may send or listen to a netlink
multicast group."
2. "NLM_F_ATOMIC requires the CAP_NET_ADMIN capability or an
effective UID of 0."
On 22/02/2017 18:24, Matt Layher wrote:
Sure, I can make a note of this. Almost everything I've done
with netlink so far has been read-only, which is probably why I
haven't run into any issues.
On Wednesday, February 22, 2017 at 1:13:26 PM UTC-5, Steven
Hartland wrote:
One thing you don't mention, which we found particularly
frustrating with netlink, is that using it can often need
cap_net_admin :(
On 22/02/2017 17:38, Matt Layher wrote:
Hey all,
I recently spent some time working with Linux's netlink IPC
mechanism in Go. Because I had a hard time finding
accurate information about netlink, I decided to do a
write-up on some of its fundamental concepts, and how I was
able to make use of them from Go.
This post focuses on how netlink sockets and messages work,
and how to work with them from Go or another language of
your choice.
You can find the first portion of that write-up, focusing
on netlink, here:
https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8
<https://medium.com/@mdlayher/linux-netlink-and-go-part-1-netlink-4781aaeeaca8>
I still have more to write regarding generic netlink and my
high-level Go netlink and wifi packages themselves (parts 2
and 3).
If you're just looking for some source code, check out:
https://github.com/mdlayher/netlink
<https://github.com/mdlayher/netlink>
https://github.com/mdlayher/wifi
<https://github.com/mdlayher/wifi>
Happy to address any questions or comments here. Thanks
for your time!
- Matt Layher
--
You received this message because you are subscribed to the
Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails
from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
