* Use CAP_NET_ADMIN and alias netdev-nlmon instead
@ 2014-08-08 21:22 Marcel Holtmann
2014-08-09 19:32 ` Daniel Borkmann
0 siblings, 1 reply; 6+ messages in thread
From: Marcel Holtmann @ 2014-08-08 21:22 UTC (permalink / raw)
To: netdev@vger.kernel.org
Hi,
so I am running this command sequence:
ip link add name nlmon type nlmon
ip link set dev nlmon up
With that I get this message in dmesg:
Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-nlmon instead.
The kernel section producing this is dev_load() from net/core/dev_ioctl.c:
no_module = !dev;
if (no_module && capable(CAP_NET_ADMIN))
no_module = request_module("netdev-%s", name);
if (no_module && capable(CAP_SYS_MODULE)) {
if (!request_module("%s", name))
pr_warn("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
name);
}
Since I am explicitly giving the name from userspace, I have no idea why the kernel bugs me in providing netdev-nlmon alias. It makes no sense to me. What is the reasoning behind this?
Regards
Marcel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Use CAP_NET_ADMIN and alias netdev-nlmon instead
2014-08-08 21:22 Use CAP_NET_ADMIN and alias netdev-nlmon instead Marcel Holtmann
@ 2014-08-09 19:32 ` Daniel Borkmann
2014-08-09 20:23 ` Marcel Holtmann
0 siblings, 1 reply; 6+ messages in thread
From: Daniel Borkmann @ 2014-08-09 19:32 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: netdev@vger.kernel.org
On 08/08/2014 11:22 PM, Marcel Holtmann wrote:
> Hi,
>
> so I am running this command sequence:
>
> ip link add name nlmon type nlmon
> ip link set dev nlmon up
>
> With that I get this message in dmesg:
>
> Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).
> Use CAP_NET_ADMIN and alias netdev-nlmon instead.
>
> The kernel section producing this is dev_load() from net/core/dev_ioctl.c:
>
> no_module = !dev;
> if (no_module && capable(CAP_NET_ADMIN))
> no_module = request_module("netdev-%s", name);
> if (no_module && capable(CAP_SYS_MODULE)) {
> if (!request_module("%s", name))
> pr_warn("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
> name);
> }
>
> Since I am explicitly giving the name from userspace, I have no idea why the
> kernel bugs me in providing netdev-nlmon alias. It makes no sense to me. What
> is the reasoning behind this?
Could it just be that your process doesn't have CAP_NET_ADMIN set
but CAP_SYS_MODULE instead thus triggering this pr_warn()?
grep Cap /proc/$$/status ?
Hm, I don't think this is nlmon related, above works fine on my side.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Use CAP_NET_ADMIN and alias netdev-nlmon instead
2014-08-09 19:32 ` Daniel Borkmann
@ 2014-08-09 20:23 ` Marcel Holtmann
2014-08-10 0:03 ` Stephen Hemminger
0 siblings, 1 reply; 6+ messages in thread
From: Marcel Holtmann @ 2014-08-09 20:23 UTC (permalink / raw)
To: Daniel Borkmann; +Cc: netdev@vger.kernel.org
Hi Daniel,
>> so I am running this command sequence:
>>
>> ip link add name nlmon type nlmon
>> ip link set dev nlmon up
>>
>> With that I get this message in dmesg:
>>
>> Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).
> > Use CAP_NET_ADMIN and alias netdev-nlmon instead.
>>
>> The kernel section producing this is dev_load() from net/core/dev_ioctl.c:
>>
>> no_module = !dev;
>> if (no_module && capable(CAP_NET_ADMIN))
>> no_module = request_module("netdev-%s", name);
>> if (no_module && capable(CAP_SYS_MODULE)) {
>> if (!request_module("%s", name))
>> pr_warn("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
>> name);
>> }
>>
>> Since I am explicitly giving the name from userspace, I have no idea why the
> > kernel bugs me in providing netdev-nlmon alias. It makes no sense to me. What
> > is the reasoning behind this?
>
> Could it just be that your process doesn't have CAP_NET_ADMIN set
> but CAP_SYS_MODULE instead thus triggering this pr_warn()?
>
> grep Cap /proc/$$/status ?
>
> Hm, I don't think this is nlmon related, above works fine on my side.
so I have not nlmon.ko loaded or compiled into the kernel. This means the ip command will trigger the autoloading. Command is either run with sudo or as root. So this is not a capability issue.
I think this is just a wrong check when handling loading of modules. I still do not understand how a netdev-%s alias makes any sense. Or even trying to load module nlmon.ko since I created interface nlmon.
The real module loading should also be done in the type and not the name.
Regards
Marcel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Use CAP_NET_ADMIN and alias netdev-nlmon instead
2014-08-09 20:23 ` Marcel Holtmann
@ 2014-08-10 0:03 ` Stephen Hemminger
2014-08-11 20:01 ` Marcel Holtmann
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2014-08-10 0:03 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Daniel Borkmann, netdev@vger.kernel.org
On Sat, 9 Aug 2014 13:23:24 -0700
Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Daniel,
>
> >> so I am running this command sequence:
> >>
> >> ip link add name nlmon type nlmon
> >> ip link set dev nlmon up
> >>
> >> With that I get this message in dmesg:
> >>
> >> Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).
> > > Use CAP_NET_ADMIN and alias netdev-nlmon instead.
> >>
> >> The kernel section producing this is dev_load() from net/core/dev_ioctl.c:
> >>
> >> no_module = !dev;
> >> if (no_module && capable(CAP_NET_ADMIN))
> >> no_module = request_module("netdev-%s", name);
> >> if (no_module && capable(CAP_SYS_MODULE)) {
> >> if (!request_module("%s", name))
> >> pr_warn("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
> >> name);
> >> }
> >>
> >> Since I am explicitly giving the name from userspace, I have no idea why the
> > > kernel bugs me in providing netdev-nlmon alias. It makes no sense to me. What
> > > is the reasoning behind this?
> >
> > Could it just be that your process doesn't have CAP_NET_ADMIN set
> > but CAP_SYS_MODULE instead thus triggering this pr_warn()?
> >
> > grep Cap /proc/$$/status ?
> >
> > Hm, I don't think this is nlmon related, above works fine on my side.
>
> so I have not nlmon.ko loaded or compiled into the kernel. This means the ip command will trigger the autoloading. Command is either run with sudo or as root. So this is not a capability issue.
>
> I think this is just a wrong check when handling loading of modules. I still do not understand how a netdev-%s alias makes any sense. Or even trying to load module nlmon.ko since I created interface nlmon.
>
> The real module loading should also be done in the type and not the name.
>
> Regards
>
> Marcel
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
The netdev module alias is a hold over from the past. For normal device people
used to create a alias eth0 to and point it to the type of network device used, that
was back in the bad old ISA days before real discovery.
Also, the tunnels create module alias for the control device and ip used to use
this to autoload the tunnel device.
The message is bogus and should just be removed, I also see it in a couple of other cases
where tap devices are renamed for other usese.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Use CAP_NET_ADMIN and alias netdev-nlmon instead
2014-08-10 0:03 ` Stephen Hemminger
@ 2014-08-11 20:01 ` Marcel Holtmann
2014-08-13 9:39 ` Daniel Borkmann
0 siblings, 1 reply; 6+ messages in thread
From: Marcel Holtmann @ 2014-08-11 20:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Daniel Borkmann, netdev@vger.kernel.org
Hi Stephen,
>>>> so I am running this command sequence:
>>>>
>>>> ip link add name nlmon type nlmon
>>>> ip link set dev nlmon up
>>>>
>>>> With that I get this message in dmesg:
>>>>
>>>> Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).
>>>> Use CAP_NET_ADMIN and alias netdev-nlmon instead.
>>>>
>>>> The kernel section producing this is dev_load() from net/core/dev_ioctl.c:
>>>>
>>>> no_module = !dev;
>>>> if (no_module && capable(CAP_NET_ADMIN))
>>>> no_module = request_module("netdev-%s", name);
>>>> if (no_module && capable(CAP_SYS_MODULE)) {
>>>> if (!request_module("%s", name))
>>>> pr_warn("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
>>>> name);
>>>> }
>>>>
>>>> Since I am explicitly giving the name from userspace, I have no idea why the
>>>> kernel bugs me in providing netdev-nlmon alias. It makes no sense to me. What
>>>> is the reasoning behind this?
>>>
>>> Could it just be that your process doesn't have CAP_NET_ADMIN set
>>> but CAP_SYS_MODULE instead thus triggering this pr_warn()?
>>>
>>> grep Cap /proc/$$/status ?
>>>
>>> Hm, I don't think this is nlmon related, above works fine on my side.
>>
>> so I have not nlmon.ko loaded or compiled into the kernel. This means the ip command will trigger the autoloading. Command is either run with sudo or as root. So this is not a capability issue.
>>
>> I think this is just a wrong check when handling loading of modules. I still do not understand how a netdev-%s alias makes any sense. Or even trying to load module nlmon.ko since I created interface nlmon.
>>
>> The real module loading should also be done in the type and not the name.
>
> The netdev module alias is a hold over from the past. For normal device people
> used to create a alias eth0 to and point it to the type of network device used, that
> was back in the bad old ISA days before real discovery.
so can we just remove the second request_module for the network interface name here. I find the warning pretty much annoying since especially in cases where the autoloading happens based on RTNL and the type it is just in the wrong order.
I mean, I told you to create this type of interface with this name. So please stop complaining to me ;)
> Also, the tunnels create module alias for the control device and ip used to use
> this to autoload the tunnel device.
>
> The message is bogus and should just be removed, I also see it in a couple of other cases
> where tap devices are renamed for other usese.
So what is the preferred way. Remove just the warning or the whole request_module of the the network interface name?
Regards
Marcel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Use CAP_NET_ADMIN and alias netdev-nlmon instead
2014-08-11 20:01 ` Marcel Holtmann
@ 2014-08-13 9:39 ` Daniel Borkmann
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Borkmann @ 2014-08-13 9:39 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Stephen Hemminger, netdev@vger.kernel.org
On 08/11/2014 10:01 PM, Marcel Holtmann wrote:
...
>>>>> so I am running this command sequence:
>>>>>
>>>>> ip link add name nlmon type nlmon
>>>>> ip link set dev nlmon up
>>>>>
>>>>> With that I get this message in dmesg:
>>>>>
>>>>> Loading kernel module for a network device with CAP_SYS_MODULE (deprecated).
>>>>> Use CAP_NET_ADMIN and alias netdev-nlmon instead.
>>>>>
>>>>> The kernel section producing this is dev_load() from net/core/dev_ioctl.c:
>>>>>
>>>>> no_module = !dev;
>>>>> if (no_module && capable(CAP_NET_ADMIN))
>>>>> no_module = request_module("netdev-%s", name);
>>>>> if (no_module && capable(CAP_SYS_MODULE)) {
>>>>> if (!request_module("%s", name))
>>>>> pr_warn("Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev-%s instead.\n",
>>>>> name);
>>>>> }
>>>>>
>>>>> Since I am explicitly giving the name from userspace, I have no idea why the
>>>>> kernel bugs me in providing netdev-nlmon alias. It makes no sense to me. What
>>>>> is the reasoning behind this?
>>>>
>>>> Could it just be that your process doesn't have CAP_NET_ADMIN set
>>>> but CAP_SYS_MODULE instead thus triggering this pr_warn()?
>>>>
>>>> grep Cap /proc/$$/status ?
>>>>
>>>> Hm, I don't think this is nlmon related, above works fine on my side.
>>>
>>> so I have not nlmon.ko loaded or compiled into the kernel. This means the ip command will trigger the autoloading. Command is either run with sudo or as root. So this is not a capability issue.
>>>
>>> I think this is just a wrong check when handling loading of modules. I still do not understand how a netdev-%s alias makes any sense. Or even trying to load module nlmon.ko since I created interface nlmon.
>>>
>>> The real module loading should also be done in the type and not the name.
>>
>> The netdev module alias is a hold over from the past. For normal device people
>> used to create a alias eth0 to and point it to the type of network device used, that
>> was back in the bad old ISA days before real discovery.
>
> so can we just remove the second request_module for the network interface name here. I find the warning pretty much annoying since especially in cases where the autoloading happens based on RTNL and the type it is just in the wrong order.
>
> I mean, I told you to create this type of interface with this name. So please stop complaining to me ;)
It can btw also be triggered when nlmon is loaded, nlmon device exists
and calling `ip link del dev nlmon` more than once. Given that the
netdev-%s alias was only introduced 'recently' [1], I'd rather just say
to go for Stephen's suggestion to not break some deprecated user space
expectations.
[1] http://thread.gmane.org/gmane.linux.kernel/1105168
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-08-13 9:39 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-08-08 21:22 Use CAP_NET_ADMIN and alias netdev-nlmon instead Marcel Holtmann
2014-08-09 19:32 ` Daniel Borkmann
2014-08-09 20:23 ` Marcel Holtmann
2014-08-10 0:03 ` Stephen Hemminger
2014-08-11 20:01 ` Marcel Holtmann
2014-08-13 9:39 ` Daniel Borkmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).