This reverts commit 0f5a529217.
As discussed in https://github.com/systemd/systemd/issues/33104,
that patch caused problems in Debian which has a udev drop-in with
[Match]
Path=*-usb-*
[Link]
NamePolicy=mac
The rename fails:
eth0: Policy *mac* yields "enx00*".
eth0: /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'enx00*'
eth0: /usr/lib/udev/rules.d/99-systemd.rules:69 RUN '/usr/lib/systemd/systemd-sysctl --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$
eth0: sd-device: Created database file '/run/udev/data/n9' for '/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:
eth0: Failed to rename network interface 9 from 'eth0' to 'enx00*': File exists
eth0: sd-device: Created database file '/run/udev/data/n9' for '/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/0000:03:01.0/0000:05:00.0/0000:
eth0: Failed to process device, ignoring: File exists
Two network interfaces have the same MAC and it's not marked NET_ADDR_STOLEN.
In this case the conflict is very visible because it causes the rename to fail,
but it would also occur in other cases, for alternative names.
A patch has been submitted for r8152 to properly set NET_ADDR_STOLEN:
https://lore.kernel.org/linux-usb/20240605153340.25694-1-gmazyland@gmail.com/T/#u
Let's revert this now to avoid a regression. We can try again after the kernel
issue is resolved.
Closes https://github.com/systemd/systemd/issues/33104.
While containers often have their host0 network provided by veth when
the container runtime is privileged, unprivileged containers tend to
have their network provided via slirp4netns or pasta. These tools use a
tun interface rather than a veth interface and systemd should still set
configure such networks.
We should have different .network files for the veth and tun use cases
as there may arise a need to configure them differently. We should not
rename 80-container-host0.network as that would cause existing drop-ins
to no longer apply.
Closes: #32095
Fixes: f139393dd2 ("network: use Kind= instead of Driver=")
Signed-off-by: Helmut Grohne <helmut@subdivi.de>
This file makes clear the interface shall be owned by networkd.
This does what 658169e6d3 did for nspawn's
regular devices for the devices defined through
8aee931e7a too.
This adds a small, socket-activated Varlink daemon that can delegate UID
ranges for user namespaces to clients asking for it.
The primary call is AllocateUserRange() where the user passes in an
uninitialized userns fd, which is then set up.
There are other calls that allow assigning a mount fd to a userns
allocated that way, to set up permissions for a cgroup subtree, and to
allocate a veth for such a user namespace.
Since the UID assignments are supposed to be transitive, i.e. not
permanent, care is taken to ensure that users cannot create inodes owned
by these UIDs, so that persistancy cannot be acquired. This is
implemented via a BPF-LSM module that ensures that any member of a
userns allocated that way cannot create files unless the mount it
operates on is owned by the userns itself, or is explicitly
allowelisted.
BPF LSM program with contributions from Alexei Starovoitov.
Spotted randomly when going through CI logs:
systemd-udevd[658]: /usr/lib/systemd/network/80-6rd-tunnel.link:21: Unknown section 'Network'. Ignoring.
Follow-up for 658169e6d3.
This is a follow-up for #30786 and uses it to assign
ID_NET_MANAGED_BY=io.systemd.Network to all all network interfaces that
we consider ours to manage. This should hopefully have the effect that
other well-behaving managers won't fight for these devices.
This doesn't bother with network interfaces we match inside containers,
since udev is not available there anyway.
I started working on integrating this in the Fedora package and realized that
the example files should be installed regardless of the renamed files when
default-network=true is used. This is because the renamed files become part of
a different package, and we want to have the other files which are used as
documentation in the main package anyway.
networkd ignores errors in reading driver through ethtool. The kind of
network interface is retrieved through netlink, and networkd checks
checks many failures. So, using Kind= should be safer.
No functional change, just for safety.
Also this renames 80-ethernet.network.example -> 89-ethernet.network.example,
to make it have lower precedence over other default .network files for
Ethernet interfaces.
Closes#29765.
This is name ".network.example" for now, to match the existing
80-ethernet.network file.
I think it would make sense to actually install this by default if told
so via a meson file (and then hopefully this would happen even on
Fedora, though in a split off RPM or so). However, we aren't there yet,
hence for now, just ship the .network files as example, like the others.
Arguably, CC0 is just fine for examples since they are not code. But it's
easier to be consistent and just use MIT-0 for all "documentation". Thus,
the license is changed similarly code examples under man/.
Based on 'git shortlog -ns network/*' and 'git log -p', the following folks
should ack this:
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Tom Gundersen
Yu Watanabe
Daan De Meyer
Marc-André Lureau
The file has instructions how to "enable" it by symlinking into the
appropriate place. If we create a different mechanism to do enablement
later on, we can always adjust the instructions.
Closes#3998.
Same justification as the previous commit.
$ for i in network/*-*; do git blame $i;done | less
shows that those files were written by Tom Gundersen, Lennart Poettering, Yu
Watanabe, me, and Marc-André Lureau.
This matches what we have for example programs under man/, and is nice
because it allows people to copy the files as they wish without worrying
about copyright. The files are too trivial to copyright anyway.
RAs trigger neighbor discovery which allows users to query the
LL address of the container/VM via `ip neighbor get dev`. This is
useful as it gives users an easy way to connect to the container
without needing LLMNR or mDNS to resolve the hostname of the container
to an IP address. In practice, this allows connecting with only
networkd enabled and without resolved running in the host/container.
This is useful for development where overwriting files out side
the configured prefix will affect the host as well as stateless
systems such as NixOS that don't let packages install to /etc but handle
configuration on their own.
Alternative to https://github.com/systemd/systemd/pull/17501
tested with:
$ mkdir inst build && cd build
$ meson \
-Dcreate-log-dirs=false \
-Dsysvrcnd-path=$(realpath ../inst)/etc/rc.d \
-Dsysvinit-path=$(realpath ../inst)/etc/init.d \
-Drootprefix=$(realpath ../inst) \
-Dinstall-sysconfdir=false \
--prefix=$(realpath ../inst) ..
$ ninja install
I think 80-wifi-adhoc.network is safe enough, since it just enables
the link-local addressing. But the other two enable DHCP in client
or server modes, and we should not do this by default.
If "keep" policy is specified, and the interface has a name that is
NET_NAME_USER or NET_NAME_RENAMED, we stop processing rules. "keep" should
probably be specified either first or last depending on the preference.
This partially reimplements 55b6530baa, in the
sense that if the "keep" policy is not specified, and if the interface has
a NamingPolicy, it will be renamed, even if it had a name previously.
So this breaks backwards compatibility in this case, but that's more in line
with what users expect.
Closes#9006.
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
So far I avoided adding license headers to meson files, but they are pretty
big and important and should carry license headers like everything else.
I added my own copyright, even though other people modified those files too.
But this is mostly symbolic, so I hope that's OK.
