shaba/systemd
1
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-11-02 19:21:53 +03:00
Code
8e143a1232
systemd/units/systemd-networkd.service.in

55 lines
1.8 KiB
SYSTEMD
Raw Normal View History

Add SPDX license headers to unit files
2017-11-18 19:35:03 +03:00
# SPDX-License-Identifier: LGPL-2.1+
#
networkd: add a basic network daemon This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured. Example .network file: [Match] Name=wlp2s0 [Network] Description=My Network Gateway=192.168.1.1 Address=192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64
2013-10-17 05:18:36 +04:00
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
[Unit]
Description=Network Service
Documentation=man:systemd-networkd.service(8)
units: minor cleanups
2014-06-17 04:18:33 +04:00
ConditionCapability=CAP_NET_ADMIN
networkd: add a basic network daemon This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured. Example .network file: [Match] Name=wlp2s0 [Network] Description=My Network Gateway=192.168.1.1 Address=192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64
2013-10-17 05:18:36 +04:00
DefaultDependencies=no
networkd: allow networkd to start in early boot With the previous improvements, networkd.service's "After=dbus.service" can now be dropped. That ordering effectively forced networkd.service to run in late boot only (dbus.service was rejected to run in early boot in https://bugs.freedesktop.org/show_bug.cgi?id=98254). Fixes #4504
2016-11-22 10:41:51 +03:00
# systemd-udevd.service can be dropped once tuntap is moved to netlink
Revert "network: set DynamicUser= to systemd-networkd.service" This reverts commit d4e9e574ea0b5d23598a317e68399584d229568b. (systemd.conf.m4 part was already reverted in 5b5d82615011b9827466b7cd5756da35627a1608.) Together those reverts should "fix" #10025 and #10011. ("fix" is in quotes because this doesn't really fix the underlying issue, which is combining DynamicUser= with strict container sandbox, but it avoids the problem by not using that feature in our default installation.) Dynamic users don't work well if the service requires matching configuration in other places, for example dbus policy. This is true for those three services. In effect, distros create the user statically [1, 2]. Dynamic users make more sense for "add-on" services where not creating the user, or more precisely, creating the user lazily, can save resources. For "basic" services, if we are going to create the user on package installation anyway, setting DynamicUser= just creates unneeded confusion. The only case where it is actually used is when somebody forgets to do system configuration. But it's better to have the service fail cleanly in this case too. If we want to turn on some side-effect of DynamicUser=yes for those services, we should just do that directly through fine-grained options. By not using DynamicUser= we also avoid the need to restart dbus. [1] https://salsa.debian.org/systemd-team/systemd/commit/bd9bf307274faca24699c0c2d67cb86f18c0b2cb [2] https://src.fedoraproject.org/rpms/systemd/blob/48ac1cebdedb055d9daf3dfe28c7bde80103f7a1/f/systemd.spec#_473 (Fedora does not create systemd-timesync user.)
2018-09-19 11:06:09 +03:00
After=systemd-udevd.service network-pre.target systemd-sysusers.service systemd-sysctl.service
units: minor cleanups
2014-06-17 04:18:33 +04:00
Before=network.target multi-user.target shutdown.target
Conflicts=shutdown.target
networkd: add a basic network daemon This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured. Example .network file: [Match] Name=wlp2s0 [Network] Description=My Network Gateway=192.168.1.1 Address=192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64
2013-10-17 05:18:36 +04:00
Wants=network.target
[Service]
networkd: use Type=notify Also start earlier during boot.
2013-11-23 05:07:08 +04:00
Type=notify
networkd: exit on idle We will be woken up on rtnl or dbus activity, so let's just quit if some time has passed and that is the only thing that can happen. Note that we will always stay around if we expect network activity (e.g. DHCP is enabled), as we are not restarted on that.
2015-02-04 17:00:20 +03:00
Restart=on-failure
networkd: add a basic network daemon This daemon listens for and configures network devices tagged with 'systemd-networkd'. By default, no devices are tagged so this daemon can safely run in parallel with existing network daemons/scripts. Networks are configured in /etc/systemd/network/*.network. The first .network file that matches a given link is applied. The matching logic is similar to the one for .link files, but additionally supports matching on interface name. The mid-term aim is to provide an alternative to ad-hoc scripts currently used in initrd's and for wired setups that don't change much (e.g., as seen on servers/and some embedded systems). Currently, static addresses and a gateway can be configured. Example .network file: [Match] Name=wlp2s0 [Network] Description=My Network Gateway=192.168.1.1 Address=192.168.1.23/24 Address=fe80::9aee:94ff:fe3f:c618/64
2013-10-17 05:18:36 +04:00
RestartSec=0
units: make use of !! ExecStart= prefix in systemd-networkd.service Let's make use of !! to run networkd with ambient capabilities on systems supporting them.
2017-08-26 19:40:47 +03:00
ExecStart=!!@rootlibexecdir@/systemd-networkd
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 14:23:27 +03:00
WatchdogSec=3min
units: make use of !! ExecStart= prefix in systemd-networkd.service Let's make use of !! to run networkd with ambient capabilities on systems supporting them.
2017-08-26 19:40:47 +03:00
User=systemd-network
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW
Revert "network: set DynamicUser= to systemd-networkd.service" This reverts commit d4e9e574ea0b5d23598a317e68399584d229568b. (systemd.conf.m4 part was already reverted in 5b5d82615011b9827466b7cd5756da35627a1608.) Together those reverts should "fix" #10025 and #10011. ("fix" is in quotes because this doesn't really fix the underlying issue, which is combining DynamicUser= with strict container sandbox, but it avoids the problem by not using that feature in our default installation.) Dynamic users don't work well if the service requires matching configuration in other places, for example dbus policy. This is true for those three services. In effect, distros create the user statically [1, 2]. Dynamic users make more sense for "add-on" services where not creating the user, or more precisely, creating the user lazily, can save resources. For "basic" services, if we are going to create the user on package installation anyway, setting DynamicUser= just creates unneeded confusion. The only case where it is actually used is when somebody forgets to do system configuration. But it's better to have the service fail cleanly in this case too. If we want to turn on some side-effect of DynamicUser=yes for those services, we should just do that directly through fine-grained options. By not using DynamicUser= we also avoid the need to restart dbus. [1] https://salsa.debian.org/systemd-team/systemd/commit/bd9bf307274faca24699c0c2d67cb86f18c0b2cb [2] https://src.fedoraproject.org/rpms/systemd/blob/48ac1cebdedb055d9daf3dfe28c7bde80103f7a1/f/systemd.spec#_473 (Fedora does not create systemd-timesync user.)
2018-09-19 11:06:09 +03:00
ProtectSystem=strict
core: rename ReadOnlySystem= to ProtectSystem= and add a third value for also mounting /etc read-only Also, rename ProtectedHome= to ProtectHome=, to simplify things a bit. With this in place we now have two neat options ProtectSystem= and ProtectHome= for protecting the OS itself (and optionally its configuration), and for protecting the user's data.
2014-06-04 20:07:55 +04:00
ProtectHome=yes
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 14:23:27 +03:00
ProtectControlGroups=yes
units: turn on ProtectKernelModules= for most long-running services
2017-02-09 13:09:50 +03:00
ProtectKernelModules=yes
units: enable MemoryDenyWriteExecute (#3459) Secure daemons shipped by systemd by enabling MemoryDenyWriteExecute. Closes: #3459
2016-06-08 15:23:37 +03:00
MemoryDenyWriteExecute=yes
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 14:23:27 +03:00
RestrictRealtime=yes
units: set RestrictNamespaces=yes to networkd and resolved Closes #8949.
2018-05-10 18:17:38 +03:00
RestrictNamespaces=yes
units: further lock down our long-running services Let's make this an excercise in dogfooding: let's turn on more security features for all our long-running services. Specifically: - Turn on RestrictRealtime=yes for all of them - Turn on ProtectKernelTunables=yes and ProtectControlGroups=yes for most of them - Turn on RestrictAddressFamilies= for all of them, but different sets of address families for each Also, always order settings in the unit files, that the various sandboxing features are close together. Add a couple of missing, older settings for a numbre of unit files. Note that this change turns off AF_INET/AF_INET6 from udevd, thus effectively turning of networking from udev rule commands. Since this might break stuff (that is already broken I'd argue) this is documented in NEWS.
2016-08-26 14:23:27 +03:00
RestrictAddressFamilies=AF_UNIX AF_NETLINK AF_INET AF_INET6 AF_PACKET
units: switch from system call blacklist to whitelist This is generally the safer approach, and is what container managers (including nspawn) do, hence let's move to this too for our own services. This is particularly useful as this this means the new @system-service system call filter group will get serious real-life testing quickly. This also switches from firing SIGSYS on unexpected syscalls to returning EPERM. This would have probably been a better default anyway, but it's hard to change that these days. When whitelisting system calls SIGSYS is highly problematic as system calls that are newly introduced to Linux become minefields for services otherwise. Note that this enables a system call filter for udev for the first time, and will block @clock, @mount and @swap from it. Some downstream distributions might want to revert this locally if they want to permit unsafe operations on udev rules, but in general this shiuld be mostly safe, as we already set MountFlags=shared for udevd, hence at least @mount won't change anything.
2018-04-19 12:04:17 +03:00
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM
units: set SystemCallArchitectures=native on all our long-running services
2017-02-09 00:32:37 +03:00
SystemCallArchitectures=native
units: set LockPersonality= for all our long-running services (#6819) Let's lock things down. Also, using it is the only way how to properly test this to the fullest extent.
2017-09-14 20:45:40 +03:00
LockPersonality=yes
units: make use of !! ExecStart= prefix in systemd-networkd.service Let's make use of !! to run networkd with ambient capabilities on systems supporting them.
2017-08-26 19:40:47 +03:00
RuntimeDirectory=systemd/netif
RuntimeDirectoryPreserve=yes
install: do not statically enable systemd-networkd [tomegun: pruned the commit message as not to contradict the follow-up commit]
2014-02-21 07:38:17 +04:00
[Install]
WantedBy=multi-user.target
networkd: support socket activation Still keep the non-socket activation code around for starting from the commandline, but will likely drop that too in the future.
2015-02-02 00:13:26 +03:00
Also=systemd-networkd.socket
Makefile.am: link dbus-org.freedesktop.network1 alias in /etc This makes dbus-org.freedesktop.network1.service like dbus-org.freedesktop.resolve1.service. When systemd-networkd.service is disabled, the alias is also removed.
2017-04-10 18:59:58 +03:00
Alias=dbus-org.freedesktop.network1.service
units: make enablement of s-n-wait-online.service follow systemd-networkd.service (#5635) In 58a6dd15582c038a25bd7059435833943e2e4617 s-n-wait-online.service was added to presets to synchronize the presets with the state after installation. But it is harmful to have s-n-wait-online.service enabled when s-n.service is disabled, because s-n-wait-online.service has Requsite=s-n.service and cannot be activated. Thus remove s-n-wait-online.service from presets again, and let it be enabled whenever s-n.service is enabled. During installation we create enablement symlinks by hand, and since s-n.service is enabled, s-n-w-o.service should be enabled too, so the symlink should still be created during installation. https://bugzilla.redhat.com/show_bug.cgi?id=1433459#c15
2017-03-27 13:55:55 +03:00
# We want to enable systemd-networkd-wait-online.service whenever this service
# is enabled. systemd-networkd-wait-online.service has
# WantedBy=network-online.target, so enabling it only has an effect if
# network-online.target itself is enabled or pulled in by some other unit.
Also=systemd-networkd-wait-online.service
Copy Permalink