summaryrefslogtreecommitdiffstats
path: root/src (follow)
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #11050 from poettering/resolved-domain-routeLennart Poettering2018-12-2118-95/+392
|\ | | | | resolved: beef up domain routing
| * resolved: read DNS default route option from networkdLennart Poettering2018-12-211-0/+25
| |
| * sd-network: add new API sd_network_link_get_dns_default_route()Lennart Poettering2018-12-212-0/+22
| | | | | | | | | | This simply reads from networkd's state files whether a link shall be used as DNS default route.
| * networkd: permit DNS "DefaultRoute" configuration in .network filesLennart Poettering2018-12-214-4/+10
| |
| * networkd: small simplificationLennart Poettering2018-12-211-8/+4
| |
| * resolvectl: add support for reading/writing per-link 'default-route' booleanLennart Poettering2018-12-211-1/+61
| |
| * resolvectl: minor whitespace fixLennart Poettering2018-12-211-1/+1
| |
| * resolved: add bus API to set per-link "default route" booleanLennart Poettering2018-12-213-0/+58
| |
| * resolved: add an explicit way to configure whether a link is useful as ↵Lennart Poettering2018-12-215-23/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | default route Previously, we'd use a link as "default" route depending on whether there are route-only domains defined on it or not. (If there are, it would not be used as default route, if there aren't it would.) Let's make this explicit and add a link variable controlling this. The variable is not changeable from the outside yet, but subsequent commits are supposed to add that. Note that making this configurable adds a certain amount of redundancy, as there are now two ways to ensure a link does not receive "default" lookup (i.e. DNS queries matching no configured route): 1. By ensuring that at least one other link configures a route on it (for example by add "." to its search list) 2. By setting this new boolean to false. But this is exactly what is intended with this patch: that there is an explicit way to configure on the link itself whether it receives 'default' traffic, rather than require this to be configured on other links. The variable added is a tri-state: if true, the link is suitable for recieving "default" traffic. If false, the link is not suitable for it. If unset (i.e. negative) the original logic of "has this route-only routes" is used, to ensure compatibility with the status quo ante.
| * resolved: rework dns_server_limited_domains(), replace by ↵Lennart Poettering2018-12-215-34/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | dns_scope_has_route_only_domains() The function dns_server_limited_domains() was very strange as it enumerate the domains associated with a DnsScope object to determine whether any "route-only" domains, but did so as a function associated with a DnsServer object. Let's clear this up, and replace it by a function associated with a DnsScope instead. This makes more sense philosphically and allows us to reduce the loops through which we need to jump to determine whether a scope is suitable for default routing a bit.
| * resolved: bind .local domains to mDNS with DNS_SCOPE_YES, similar LLMNRLennart Poettering2018-12-211-8/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, we'd return DNS_SCOPE_MAYBE for all domain lookups matching LLMNR or mDNS. Let's upgrade this to DNS_SCOPE_YES, to make the binding stronger. The effect of this is that even if "local" is defined as routing domain on some iface, we'll still lookup domains in local via mDNS — if mDNS is turned on. This should not be limiting, as people who don't want such lookups should turn off mDNS altogether, as it is useless if nothing is routed to it. This also has the nice benefit that mDNS/LLMR continue to work if people use "~." as routing domain on some interface. Similar for LLMNR and single label names. Similar also for the link local IPv4 and IPv6 reverse lookups. Fixes: #10125
| * resolved: rework how we determine which scope to send a query toLennart Poettering2018-12-213-20/+47
| | | | | | | | Fixes: #10830 #9825 #9472
| * resolved: add comment, explaining when Scope variables are copied from LinkLennart Poettering2018-12-211-0/+2
| |
| * resolved: rename_DNS_SCOPE_INVALID → _DNS_SCOPE_MATCH_INVALIDLennart Poettering2018-12-211-1/+1
| | | | | | | | | | The _INVALID and _MAX enum fields should always use the full name of thenum.
| * resolved: check dns_over_tls_mode in link_needs_save()Lennart Poettering2018-12-211-1/+2
| | | | | | | | This was forgotten when DoT was added.
| * resolved: use structured initialization for DnsScopeLennart Poettering2018-12-211-6/+8
| |
* | Merge pull request #11210 from thom311/dhcp-set-client-id-no-invalLennart Poettering2018-12-214-22/+27
|\ \ | | | | | | dhcp: don't enforce hardware address length for sd_dhcp_client_set_client_id()
| * | dhcp6: don't enforce DUID content for sd_dhcp6_client_set_duid()Thomas Haller2018-12-204-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are various functions to set the DUID of a DHCPv6 client. However, none of them allows to set arbitrary data. The closest is sd_dhcp6_client_set_duid(), which would still do validation of the DUID's content via dhcp_validate_duid_len(). Relax the validation and only log a debug message if the DUID does not validate. Note that dhcp_validate_duid_len() already is not very strict. For example with DUID_TYPE_LLT it only ensures that the length is suitable to contain hwtype and time. It does not further check that the length of hwaddr is non-zero or suitable for hwtype. Also, non-well-known DUID types are accepted for extensibility. Why reject certain DUIDs but allowing clearly wrong formats otherwise? The validation and failure should happen earlier, when accepting the unsuitable DUID. At that point, there is more context of what is wrong, and a better failure reason (or warning) can be reported to the user. Rejecting the DUID when setting up the DHCPv6 client seems not optimal, in particular because the DHCPv6 client does not care about actual content of the DUID and treats it as opaque blob. Also, NetworkManager (which uses this code) allows to configure the entire binary DUID in binary. It intentionally does not validate the binary content any further. Hence, it needs to be able to set _invalid_ DUIDs, provided that some basic constraints are satisfied (like the maximum length). sd_dhcp6_client_set_duid() has two callers: both set the DUID obtained from link_get_duid(), which comes from configuration. `man networkd.conf` says: "The configured DHCP DUID should conform to the specification in RFC 3315, RFC 6355.". It does not not state that it MUST conform. Note that dhcp_validate_duid_len() has another caller: DHCPv4's dhcp_client_set_iaid_duid_internal(). In this case, continue with strict validation, as the callers are more controlled. Also, there is already sd_dhcp_client_set_client_id() which can be used to bypass this check and set arbitrary client identifiers.
| * | dhcp: don't enforce hardware address length for sd_dhcp_client_set_client_id()Thomas Haller2018-12-201-18/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | sd_dhcp_client_set_client_id() is the only API for setting a raw client-id. All other setters are more restricted and only allow to set a type 255 DUID. Also, dhcp4_set_client_identifier() is the only caller, which already does: r = sd_dhcp_client_set_client_id(link->dhcp_client, ARPHRD_ETHER, (const uint8_t *) &link->mac, sizeof(link->mac)); and hence ensures that the data length is indeed ETH_ALEN. Drop additional input validation from sd_dhcp_client_set_client_id(). The client-id is an opaque blob, and if a caller wishes to set type 1 (ethernet) or type 32 (infiniband) with unexpected address length, it should be allowed. The actual client-id is not relevant to the DHCP client, and it's the responsibility of the caller to generate a suitable client-id. For example, in NetworkManager you can configure all the bytes of the client-id, including such _invalid_ settings. I think it makes sense, to allow the user to fully configure the identifier. Even if such configuration would be rejected, it would be the responsibility of the higher layers (including a sensible error message to the user) and not fail later during sd_dhcp_client_set_client_id(). Still log a debug message if the length is unexpected.
| * | dhcp: fix sd_dhcp_client_set_client_id() for infiniband addressesThomas Haller2018-12-201-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Infiniband addresses are 20 bytes (INFINIBAND_ALEN), but only the last 8 bytes are suitable for putting into the client-id. This bug had no effect for networkd, because sd_dhcp_client_set_client_id() has only one caller which always uses ARPHRD_ETHER type. I was unable to find good references for why this is correct ([1]). Fedora/RHEL has patches for ISC dhclient that also only use the last 8 bytes ([2], [3]). RFC 4390 (Dynamic Host Configuration Protocol (DHCP) over InfiniBand) [4] does not discuss the content of the client-id either. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1658057#c29 [2] https://bugzilla.redhat.com/show_bug.cgi?id=660681 [3] https://src.fedoraproject.org/rpms/dhcp/blob/3ccf3c8d815df4b8e11e1a04850975f099273d5d/f/dhcp-lpf-ib.patch [4] https://tools.ietf.org/html/rfc4390
* | | tree-wide: make new/new0/malloc_multiply/reallocarray safe for size 0Zbigniew Jędrzejewski-Szmek2018-12-212-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All underlying glibc calls are free to return NULL if the size argument is 0. We most often call those functions with a fixed argument, or at least something which obviously cannot be zero, but it's too easy to forget. E.g. coverity complains about "rows = new0(JsonVariant*, n_rows-1);" in format-table.c There is an assert that n_rows > 0, so we could hit this corner case here. Let's simplify callers and make those functions "safe". CID #1397035. The compiler is mostly able to optimize this away: $ size build{,-opt}/src/shared/libsystemd-shared-239.so (before) text data bss dec hex filename 2643329 580940 3112 3227381 313ef5 build/src/shared/libsystemd-shared-239.so (-O0 -g) 2170013 578588 3089 2751690 29fcca build-opt/src/shared/libsystemd-shared-239.so (-03 -flto -g) (after) text data bss dec hex filename 2644017 580940 3112 3228069 3141a5 build/src/shared/libsystemd-shared-239.so 2170765 578588 3057 2752410 29ff9a build-opt/src/shared/libsystemd-shared-239.so
* | | analyze: add assert to verify we are not dividing by 0Zbigniew Jędrzejewski-Szmek2018-12-211-0/+1
| | | | | | | | | | | | CID #1397051.
* | | udevadm: add two more assertionsYu Watanabe2018-12-211-2/+2
| |/ |/| | | | | | | | | Suggested by Coverity. Closes CID#1397033 and CID#1395708.
* | Merge pull request #11223 from poettering/read-line-0x00-0xffLennart Poettering2018-12-202-9/+16
|\ \ | | | | | | fileio: fix read_one_line() when reading bytes > 0x7F
| * | test-fileio: add explicit check for safe_fgetc() with 0xFFLennart Poettering2018-12-201-4/+5
| | |
| * | fileio: fix read_one_line() when reading bytes > 0x7FLennart Poettering2018-12-202-5/+11
| | | | | | | | | | | | Fixes: #11218
* | | Merge pull request #11222 from keszybz/tmpfiles-crashLennart Poettering2018-12-202-9/+73
|\ \ \ | |/ / |/| | tmpfiles: fix crash with NULL in arg_root and other fixes and tests
| * | tmpfiles: fix crash with NULL in arg_root and other fixes and testsZbigniew Jędrzejewski-Szmek2018-12-202-9/+73
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | The function to replacement paths into the configuration file list was borked. Apart from the crash with empty root prefix, it would incorrectly handle the case where root *was* set, and the replacement file was supposed to override an existing file. prefix_root is used instead of path_join because prefix_root removes duplicate slashes (when --root=dir/ is used). A test is added. Fixes #11124.
* | Merge pull request #10912 from poettering/gpt-root-rwZbigniew Jędrzejewski-Szmek2018-12-202-53/+137
|\ \ | | | | | | make sure to propagate GPT root partition r/w flag into mount r/w flag
| * | gpt-auto: propagate gpt partition ro/rw flag into root mountLennart Poettering2018-12-181-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This ensures that the read/write state of the root mount matches the read/write flag in the GPT partition table entry. This is only used as fallback in case no ro/rw flag is specified on the kernel cmdline, and there's no entry for the root partition in /etc/fstab. This is missing functionality of the GPT auto logic, as without this the root partition was always mounted read-only — when booting with zero configuration in /etc/fstab and /proc/cmdline —, as we defaulted to read-only behaviour for all mounts. Moreover we honoured the r/o flag in the partition table for all other partition types, except for the root partition.
| * | gpt-auto: make arg_root_rw a tri-stateLennart Poettering2018-12-181-2/+2
| | | | | | | | | | | | | | | No change in behaviour, but let's track whether ro or rw are specified on the kernel cmdline at all.
| * | remount-fs: optionally remount / writable, if we are told through an env varLennart Poettering2018-12-181-30/+60
| | |
| * | remount-fs: split code for tracking PIDs in hashmapLennart Poettering2018-12-181-18/+29
| | | | | | | | | | | | Just some refactoring, no change in behaviour.
| * | remount-fs: use PATH_IN_SET() at one more placeLennart Poettering2018-12-181-2/+1
| | |
| * | gpt-auto: compare kernel cmdline args with proc_cmdline_key_streq()Lennart Poettering2018-12-181-5/+6
| | |
* | | dissect: add some assert()sLennart Poettering2018-12-191-0/+15
| | |
* | | gpt-auto-generator: don't wait for udevLennart Poettering2018-12-193-10/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Generators run in a context where waiting for udev is not an option, simply because it's not running there yet. Hence, let's not wait for it in this case. This is generally OK to do as we are operating on the root disk only here, which should have been probed already by the time we come this far. An alternative fix might be to remove the udev dependency from image dissection again in the long run (and thus replace reliance on /dev/block/x:y somehow with something else). Fixes: #11205
* | | Revert "core/mount: minimize impact on mount storm."Zbigniew Jędrzejewski-Szmek2018-12-192-76/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 89f9752ea08f516b5d77f8e577bb772073c70c01. This patch causes various problems during boot, where a "mount storm" occurs naturally. Current approach is flakey, and it seems very risky to push a feature like this which impacts boot right before a release. So let's revert for now, and consider a more robust solution after later. Fixes #11209. > https://github.com/systemd/systemd/pull/11196#issuecomment-448523186: "Reverting 89f9752ea08f516b5d77f8e577bb772073c70c01 and fcfb1f775ed0e9d282607bb118ba788b98952855 fixes this test."
* | | Revert "mount: disable mount-storm protection while mount unit is starting."Zbigniew Jędrzejewski-Szmek2018-12-192-25/+1
| |/ |/| | | | | This reverts commit fcfb1f775ed0e9d282607bb118ba788b98952855.
* | mount: disable mount-storm protection while mount unit is starting.NeilBrown2018-12-192-1/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The starting of mount units requires that changes to /proc/self/mountinfo be processed before the SIGCHILD from the completion of /sbin/mount is processed, as described by the comment /* Note that due to the io event priority logic, we can be sure the new mountinfo is loaded * before we process the SIGCHLD for the mount command. */ The recently-added mount-storm protection can defeat this as it will sometimes deliberately delay processing of /proc/self/mountinfo. So we need to disable mount-storm protection when a mount unit is starting. We do this by keeping a counter of the number of pending mounts, and disabling the protection when this is non-zero. Thanks to @asavah for finding and reporting this problem.
* | Merge pull request #11182 from poettering/fileio-more-paranoiaLennart Poettering2018-12-187-110/+176
|\ \ | | | | | | More safety checks for fileio.c
| * | test-fileio: test safe_fgetc directlyZbigniew Jędrzejewski-Szmek2018-12-181-2/+30
| | | | | | | | | | | | | | | Non-ascii chars are used so that we get both "positive" and "negative" characters (on the arches where char is signed).
| * | process-util: rework getenv_for_pid() to use read_nul_string()Lennart Poettering2018-12-181-19/+16
| | |
| * | test: add test case for read_nul_string()Lennart Poettering2018-12-181-0/+35
| | |
| * | fileio: let's minimize 'count' inc/dec callsLennart Poettering2018-12-181-4/+3
| | | | | | | | | | | | | | | instead of increasing it and immediately after decreasing it again, let's just increase it a bit later.
| * | fileio: replace read_nul_string() by read_line() with a special flagLennart Poettering2018-12-183-53/+27
| | | | | | | | | | | | | | | | | | | | | read_line() is a lot more careful and optimized than read_nul_string() but does mostly the same thing. let's replace the latter by the former, just with a special flag that toggles between the slightly different EOL rules if both.
| * | process-util: make get_process_environ() saferLennart Poettering2018-12-181-10/+17
| | | | | | | | | | | | Let's add a size limit, and let's use safe_fgetc().
| * | tree-wide: port some code over to safe_fgetc()Lennart Poettering2018-12-183-23/+20
| | |
| * | fileio: add new safe_fgetc() helper callLennart Poettering2018-12-182-0/+29
| |/ | | | | | | | | We have very similar code whenever we call fgetc() in place, let's replae it by a common implementation.
* / json: do not unescape slashesZbigniew Jędrzejewski-Szmek2018-12-181-4/+0
|/ | | | | | | | | | Apparently this originated in PHP, so the json output could be directly embedded in HTML script tags. See https://stackoverflow.com/questions/1580647/json-why-are-forward-slashes-escaped. Since the output of our tools is not intended directly for web page generation, let's not do this unescaping. If needed, the consumer can always do escaping as appropriate for the target format.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 11:28:12 +0100