Open topimiettinen opened 4 years ago
I'm not sure this is a practical problem for most people using network labeling today, but that doesn't mean we can't try to solve it anyway ;)
It sounds like the udev based approach would be the easiest, would you care to work on that @topimiettinen?
Sure. I have this problem even with fixed devices: netlabel-config
starts before one of the drivers is loaded or at least the interface is not usable at that time.
I think the udev rule should look like something like this:
SUBSYSTEM!="net", GOTO="netlabel_end"
RUN+="netlabel-config-netif udev-action:$env{ACTION} device:$env{DEVNAME}"
LABEL="netlabel_end"
In case of udev-action:add
, netlabel-config-netif
should apply rules matching the device in /etc/netlabel.rules
.
In case of udev-action:remove
, netlabel-config-netif
should remove kernel rules matching the device.
Instead of new command netlabel-config-netif
, it may make sense to just extend netlabel-config
with new verbs, for example netlabel-config udev-action:...
.
If the udev rules are called for all interfaces including lo
(not sure), it would make netlabel-config
somewhat redundant except for global rules like unlbl accept off
. These could be applied on the first invocation and deleted when the last interface is removed (though I guess that never happens for lo
).
If 100% compatibility with previous setups is needed, new dynamic actions could be opted in with a new global rule in /etc/netlabel.rules
like udev-rules on/off
or the dynamic rules could be located in a new file /etc/netlabel.udev-rules
or /etc/netlabel.rules.d/*.rules
with one file per interface.
Added PR #9.
It's possible that at the time when
netlabel-config
is started at boot, some network interfaces aren't yet available. The reason for that could be that the corresponding kernel module isn't (fully) loaded yet, or the hardware is simply inserted later (like USB network adapters or putting a laptop in a docking station). Withnetlabelctl
however it's not possible to manage interfaces which are not (yet) present.I suppose this could be fixed by changing
netlabelctl
and kernel so that rules could be stored also for nonexistent interfaces. But a more dynamic way could be to utilizeudevd
so that when new network hardware is found,netlabelctl
would be launched (for example via something likenetlabelctl@.service
) to configure the new interface. This would not require changes to kernel.