network: allow empty assignment to PreferredLifetime=
Users might want to use that to unset a previous setting. The docs seem OK as
they are: we don't need to explictly mention the empty value, since it is
almost always allowed.
network: use consistent type when parsing lifetimes
Those fields are both uint32_t, so we should use the same type when parsing.
Having a different type didn't change the result, but let's be consistent.
Dana Olson [Thu, 21 May 2020 20:41:25 +0000 (16:41 -0400)]
ACCEL_MOUNT_MATRIX for additional Acer Spin model
This fixes the broken rotation on the Acer Spin 1 I recently bought (exact model is SP111-34N-P4BZ).
It is possible that all of the SP111 models would use the same matrix, but to be on the safe side, I added a new entry.
Peter Hutterer [Thu, 21 May 2020 07:33:13 +0000 (17:33 +1000)]
hwdb: remove support for MOUSE_WHEEL_TILT_*
This has now been deprecated in libinput, the only known user of this
property. It was never set for any device and weston and mutter, maybe
other compositors, never added the code required to parse it.
The benefit we could get in the UI from handling tilt differently to
wheel is tiny and the lack of support shows that it isn't of interest to
anyone. Let's remove this.
See also
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/444
$ ./out/fuzz-network-parser ./crash
INFO: Seed: 1158717610
INFO: Loaded 2 modules (199728 inline 8-bit counters): 136668 [0x7faf3e91a930, 0x7faf3e93bf0c), 63060 [0xadf190, 0xaee7e4),
INFO: Loaded 2 PC tables (199728 PCs): 136668 [0x7faf3e93bf10,0x7faf3eb51cd0), 63060 [0xaee7e8,0xbe4d28),
./out/fuzz-network-parser: Running 1 inputs 1 time(s) each.
Running: ./crash
Assertion 's' failed at src/basic/parse-util.c:458, function int safe_atou8(const char *, uint8_t *)(). Aborting.
==5588== ERROR: libFuzzer: deadly signal
#0 0x51811e in __sanitizer_print_stack_trace (/home/vagrant/systemd/out/fuzz-network-parser+0x51811e)
#1 0x46b921 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/out/fuzz-network-parser+0x46b921)
#2 0x44ded6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (/home/vagrant/systemd/out/fuzz-network-parser+0x44ded6)
#3 0x44df9d in fuzzer::Fuzzer::StaticCrashSignalCallback() (/home/vagrant/systemd/out/fuzz-network-parser+0x44df9d)
#4 0x7faf3d6d7b1f (/lib64/libpthread.so.0+0x14b1f)
#5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624)
#6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8)
#7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9
#8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9
#9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21
#10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32
#11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16
#12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21
#13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21
#14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16
#15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13
#16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16
#17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8)
#18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505)
#19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449)
#20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6)
#21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
#22 0x42c4fd in _start (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4fd)
NOTE: libFuzzer has rudimentary signal handlers.
Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal
homed: don't insist on authentication against host-copy user record
homed maintains two or three copies of the user's identity record per
home directory: one on the host, one inside the LUKS header, and one
embedded in the home directory.
Previously we'd insist that if a user logs in they have to authenticate
against all three, as a safety feature. This broke logging into
unfixated records however, since in that case the host version is
synthetic and thus does not carry any authentication data.
Let's hence losen the strictness here: accept authentication against
host records that carry no auth data. This should be safe as we know
after all that the second/third record will catch invalid accesses.
Frantisek Sumsal [Thu, 21 May 2020 14:59:40 +0000 (16:59 +0200)]
meson: add fuzz-tests= option
The slow-tests= option already enables fuzzers as well, however, this
option can't be used in the "fully sanitized" runs, as certain slow
tests are affected by the performance quite significantly.
This option allows us to enable only fuzzers without the slow tests to
meet the needs of such runs.
Defines how link-local and autoconf addresses are generated.
0: generate address based on EUI64 (default)
1: do no generate a link-local address, use EUI64 for addresses generated
from autoconf
2: generate stable privacy addresses, using the secret from
stable_secret (RFC7217)
3: generate stable privacy addresses, using a random secret if unset
Jeremy Cline [Fri, 15 May 2020 20:28:35 +0000 (16:28 -0400)]
shared: treat generator units as vendor units
Units created with "systemctl edit --full" from generator units aren't
removed with "systemctl revert" because units in the generator,
generator_early, and generator_late paths aren't considered vendor
units.
Alter path_is_vendor() to return true if the given path is a
generator unit, which in turn causes "systemctl revert" to remove units
created with "systemctl edit --full" as they now have vendor versions.
ATA devices should use the ATA ids like port number and (possibly)
master/slave or multiplier id, not the generic SCSI ID.
Currently only port number is included in the link. With this patch
the link would be able to support more cases, which are a) when the
device is behind a port multiplexer b) the distinction between master
and slave (distinguished by target id).
I tried to verify scenario a) with this patch, but I failed to find a
machine with PMP SATA devices attached. But the link below
https://github.com/systemd/systemd/issues/3943
could show what's the difference. Here is my test for scenario b)
Changelog:
v5: add another parameter compat_link in handle_scsi()
v4: comment for ID_PATH_ATA_COMPAT
get string length with pointer difference
(suggested by Franck Bui<fbui@suse.com>)
v3: creating compatible link from env
variables type change
v2: remove udev rules modification for compatible link
setup a test scenario of master/slave ATA devices
v1: initial patch
We generally return > 1 if any of the actions we are doing is instantly
complete and == 0 when we started doing it asynchronously (by forking
off homework), in our functions that execute operations on homes.
Fix a mix-up where the test for this was reversed in
home_dispatch_release() and home_dispatch_lock_all().
proc-cmdline: make checking of EFI options variable optional
And do not use it in the IMPORT{cmdline} udev code. Wherever we expose
direct interfaces to check the kernel cmdline, let's not consult our
systemd-specific EFI variable, but strictly use the actual kernel
variable, because that's what we claim we do. i.e. it's fine to use the
EFI variable for our own settings, but for the generic APIs to the
kernel cmdline we should not use it.
Specifically, this applies to IMPORT{cmdline} and
ConditionKernelCommandLine=. In the latter case we weren#t checking the
EFI variable anyway, hence let's do the same for the udev case, too.
bus-message: fix negative offset with ~empty message
In the linked reproducer, m->fields_size == 0, and we calculate ri == -1, which
of course doesn't end well. Skip the whole calculation if m->fields_size == 0,
and also check that we don't go negative even if it is non-zero.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=19446 and #15583.
udev: when random MACs are requested, generate them with genuine randomness
This is a security feature, and we thus shouldn't derive the random MACs
from a potentially guessable source. MAC addresses are after all facing
to the outside, and can be interacted with from untrusted environments.
Hence, let's generate them the same way as we generate UUIDs: from
getrandom() or /dev/urandom, and optionally with RDRAND if that's
supported.
RDRAND should be fine, since this is not cryptographic key material, but
ultimately public information. We just want to make sure conflicts are
not likely.
Previously we'd generate the MACs via rand(), which means given the
short seed they are a little bit too guessable, making collisions too
likely. See #14355 in particular.
Fixes: #14355
(Note that #14355 was already fixed by a0f11d1d11a546f791855ec9c47c2ff830e6a5aa, but I think we should do
better even, and not rely on rand() and uninitialized random pools)
sd-network: DHCPv6 - Add support to send vendor class data
```
21.16. Vendor Class Option
This option is used by a client to identify the vendor that
manufactured the hardware on which the client is running. The
information contained in the data area of this option is contained in
one or more opaque fields that identify details of the hardware
configuration. The format of the Vendor Class option is:
enterprise-number The vendor's registered Enterprise Number as
maintained by IANA [IANA-PEN]. A 4-octet
field containing an unsigned integer.
vendor-class-data The hardware configuration of the node on
which the client is running. A
variable-length field (4 octets less than the
value in the option-len field).
The vendor-class-data field is composed of a series of separate
items, each of which describes some characteristic of the client's
hardware configuration. Examples of vendor-class-data instances
might include the version of the operating system the client is
running or the amount of memory installed on the client.
Each instance of vendor-class-data is formatted as follows:
The vendor-class-len field is 2 octets long and specifies the length
of the opaque vendor-class-data in network byte order.
Servers and clients MUST NOT include more than one instance of
OPTION_VENDOR_CLASS with the same Enterprise Number. Each instance
of OPTION_VENDOR_CLASS can carry multiple vendor-class-data
instances.
```
Let's make sure we always apply the process properties from the user
record, in all our three successful paths:
1. when we register a regular session
2. when we run for the systemd --user session
3. when we have no logind (but might still have complex user records
from elsewhere) and thus exit early
cryptsetup: optionally, see if empty password works for unlocking the file system
This adds a new switch try-empty-password. If set and none of PKCS#11 or
key files work, it is attempted to unlock the volume with an empty
password, before the user is asked for a password.
Usecase: an installer generates an OS image on one system, which is the
booted up for the first time in a possibly different system. The image
is encrypted using a random volume key, but an empty password. A tool
that runs on first boot then queries the user for a password to set or
enrols the volume in the TPM, removing the empty password. (Of course, in
such a scenario it is important to never reuse the installer image on
multiple systems as they all will have the same volume key, but that's a
different question.)
Let's make loading of keys a bit more automatic and define a common
place where key files can be placed. Specifically, whenever a volume of
name "foo" is attempted, search for a key file in
/etc/cryptsetup-keys.d/foo.key and /run/cryptsetup-keys.d/foo.key,
unless a key file is declared explicitly.
With this scheme we have a simple discovery in place that should make it
more straightfoward wher to place keys, and requires no explicit
configuration to be used.
projects / thirdparty / systemd.git / log
