On 10/24/2017 02:55 PM, Othman, Ossama wrote:
On Tue, Oct 24, 2017 at 10:44 AM, Denis Kenzior <denkenz(a)gmail.com
On 10/24/2017 12:13 PM, Othman, Ossama wrote:
While looking at ELL's generic netlink code, I noticed that
l_genl_new() is part of the public API but it's not clear if the
returned struct l_genl instance is fully usable since its pid
field isn't set as in l_genl_new_default(), and since there's is
no way to set it afterward. This could result in the underlying
sockaddr_nl nl_pid field being different from l_genl's pid field
(zero in this case). Is that correct?
We don't actually use l_genl_new anywhere. And it is not unit
tested. However, looking at man 7 netlink, it states that nl_pid
should be set to 0 whenever the destination is in the kernel (which
for us is always the case at the moment). So I'm not sure that the
pid field is even needed? At least setting nl_pid to 0 in
can_write_data doesn't seem to break anything.
In l_genl_new_default(), the zero valued nl_pid field is set to a
non-zero value after the call to bind(), which is then assigned to
l_genl's pid field for later use in can_write_data(). I don't know
Correct. However note that we use the pid field to set the nlmsg_pid
field. Which the kernel never looks at as far as I can tell.
Everything in the kernel uses the actual socket nl_pid, which makes
sense anyway otherwise you could fake who you are.
enough about the netlink implementation in the kernel to understand
the nl_pid value assigned by the kernel during the call to bind() makes
a difference, but if it does wouldn't we need to keep the l_genl pid
In theory you are correct. However it doesn't appear that nlmsg_pid
field is ever looked at. Hence my earlier question of whether this
tracking code and the pid member value is even needed.