This repository was archived by the owner on Aug 6, 2020. It is now read-only.
Closed
Conversation
…ostname When /etc/hostname isn't set, default to the configured compile-time fallback hostname instead of "localhost" for the kernel hostname.
This changes resolved to use the compile-time fallback hostname the configured one is not set. Note that if the local hostname is set to "localhost" then we'll instead default to "linux" here, as for mDNS/LLMNR exposing "localhost" is actively dangerous.
UID/GID mapping with userns can be arbitrarily complex. Let's break this down to a single admin-friendly parameter: let's expose the UID/GID shift of a container via a new bus call for each container, and let's show this as part of "machinectl status" if it is not 0. This should work for pretty much all real-life full OS container setups (i.e. the stuff machined is suppose to be useful for). For everything else we generate a clean error, clarifying that we can't expose the mapping.
With this change we'll not show an "Addresses" field for machines that we don't know any addresses for. This changes print_addresses() to never suffix its output with a newline, leaving that to the caller. That's a good idea since depending on who the caller is, different rules apply: if no addresses are found, then the list view still wants a newline, but the status view does not. This also changes the function to return the number of found addresses, which can be used to decide when to add a newline or not.
…ameter This adds a unified "copy_flags" parameter to all copy_xyz() function calls, replacing the various boolean flags so far used. This should make many invocations more readable as it is clear what behaviour is precisely requested. This also prepares ground for adding support for more modes later on.
This changes the file copy logic of machined to set the UID/GID of all copied files to 0 if the host and container do not share the same user namespace. Fixes: systemd#4078
Actually initialize the "error" structure with the error we got
…applied As the kernel won't map the UIDs this is simply not safe, and hence we should generate a clean error and refuse it. We can restore this feature later should a "shiftfs" become available in the kernel.
This ensures that configured NTAs exclude not only the listed domain but also all domains below it from DNSSEC validation -- except if a positive trust anchor is defined below (as suggested by RFC7647, section 1.1) Fixes: systemd#5048
For the wildcard NSEC check we need to generate an "asterisk" domain, by prepend the common ancestor with "*.". So far we did that with a simple strappenda() which is fine for most domains, but doesn't work if the common ancestor is the root domain as we usually write that as "." in normalized form, and "*." joined with "." is "*.." and not "*." as it should be. Hence, use the clean way out, let's just use dns_name_concat() which only exists precisely for this reason, to properly concatenate labels. There's a good chance this actually fixes systemd#5029, as this NSEC proof is triggered by lookups in the TLD "example", which doesn't exist in the Internet.
…sh caches The cache might contain all kinds of unauthenticated data that we really shouldn't be using if we upgrade our feature level and suddenly are able to get authenticated data again. Might fix: systemd#4866
Doesn't really change anything, but makes things a bit simpler to read.
When we managed to prove non-existance of a name, then we should properly propagate this to clients by setting the AD bit on NXDOMAIN. See: systemd#4621
…authentication bool even on failure Let's make sure that if we accept a query candidate, then let's also propagate the authenticated flag for it, so that we can properly report back to the clients whether lookups failed due to non-existance that can be proven.
… level There's no point in talking to a server in DNSSEC mode when we don't actually want to verify anything. See: systemd#5352
When we are doing a TCP transaction the kernel will automatically resend all packets for us, there's no need to do that ourselves. Hence: increase the timeout for TCP transactions substantially, to give the kernel enough time to connect to the peer, without interrupting it when we become impatient.
Some domains (such as us.ynuf.alipay.com) almost appear as if they actively want to sabotage our DNSSEC work. Specifically, they unconditionally return SERVFAIL on SOA lookups and always only after a 1s delay (at least). This is pretty bad for our validation logic, as we use SOA lookups to distuingish zones from non-terminal names. Moreover, SERVFAIL is an error that is typically returned if we send requests a server doesn't grok, and thus is reason for us to downgrade our protocol and try again. In case of these zones this means we'll accept the SERVFAIL response only after a full iterative downgrade to our lowest feature level: TCP. In combination with the 1s delays this has the effect of making us hit our transaction timeout way to easily. As first attempt to improve the situation: let's start caching SERVFAIL responses in our cache, after the full downgrade for a short period of time. Conceptually this is exposed as "weird rcode" caching, but for now we only consider SERVFAIL a "weird rcode" worthy of caching. Later on we might want to add more.
Retrying a transaction via TCP is a good approach for mitigating packet loss. However, it's not a good away way to fix a bad RCODE if we already downgraded to UDP level for it. Hence, don't do this. This is a small tweak only, but shortens the time we spend on downgrading when a specific domain continously returns a bad rcode.
This is the most important piece of information of replies, hence show this in the first log message about it. (Wireshark shows it too in the short summary, hence this definitely makes sense...)
…e_lookup() Following our coding style on success we should initialize all return parameters of a function. We missed to cases for dns_cache_lookup() (but covered all others), fix them too.
Let's increase a number of timeouts as they apparently are too short for some real-world lookups. See: systemd#4003 (comment) In particular we change the following timeouts: 1) The first UDP retry we increase 500ms → 750ms. This is a good idea, since some servers need relatively long responses for trivial lookups, and giving up our first attempt also has the effect of trying a different server for the next attempt which has the side effect that we'll run two down-grade iterations in parallel, on both servers. Hence, let's give servers a bit more time in the first iteration. 2) Permit 24 retries instead of just 16 per transactions. If we end up downgrading all the way down to UDP for a lookup we already need 5 iterations for that. If we want permit a couple of lost packages for each (let's say 4), then we already need 20 iterations. 3) Increase the overall query timeout on the service side to 60s (from 45s), simply because very long and slow DNSSEC + CNAME chains (such as us.ynuf.alipay.com) hit this boundary too easily. The client side timeout for the bus method call is increased to 90s, in order to have room for the dbus reply to go through
For caching negative replies we need the SOA TTL information. Hence, let's authenticate all auxiliary SOA RRs through DS requests on all negative requests.
When we encounter a "special" crash we should not continue processing it the usual way.
(Note that we only do this for the journal metadata, not for the xattrs, as the xattrs are only supposed to store the original 1:1 info we acquired from the kernel.)
strsignal() sucks, as it tries to generate human readable strings from something that isn't really human readable by concept. Let's use signal_to_string() instead, making this more grokkable. Difference is: SIGINT gets translated → "SIGINT" rather than → "Interrupted".
…off trailing zeroes Our coredump handler operates on a "context" supplied by the kernel via the core_pattern arguments. When we pass off a coredump for processing to coredumpd we pass along enough information for this context to be reconstructed. This information is passed in the usual journal fields, and that means we extended the 1s granularity timestamp to 1µs granularity by appending 6 zeroes. We need to chop them off again when reconstructing the original kernel context. Fixes: systemd#4779
…edump file We didn't include the resource limit field, add it.
fallback hostname fixes
…serns machined userns fixes
In NixOS containers, the init script is bind-mounted into the container, so checking early whether it exists will fail.
We need to override these in NixOS, but you can't override an ExecStart line.
systemd-tmpfiles-setup.service pulls in local-fs.target, which interferes with NixOps' send-keys feature (since sshd.service depends indirectly on sysinit.target). Since in NixOS we don't use systemd-tmpfiles for creating files (that's done by activation scripts and preStart scripts), it's not a problem to start it a bit later.
Look in /nix/var/nix/profiles/default/lib/systemd for units provided by packages in the default (system-wide) profile, and in /etc/systemd-mutable/system for persistent, mutable units (not recommended). Also, remove /usr and /lib as these don't exist on NixOS.
We don't need it on NixOS.
33f4586 wasn't enough.
Namely lots of variants of Unit nix-var-nix-db.mount is bound to inactive unit dev-disk-by\x2dlabel-nixos.device. Stopping, too. in containers.
Patch by vcunat.
Similar to MemoryMax=, MemorySwapMax= limits swap usage. This controls controls "memory.swap.max" attribute in unified cgroup. (cherry picked from commit 96e131e)
NixOS uses this path.
NixOS has an option to link the xkb data files to /etc/X11, but not to /usr/share/X11.
Setting concrete is not covered in configuration.nix. This action is similar to `date -s`, so there is no good reason to disallow this. This option was disabled in ce02fb7
Mic92
commented
May 28, 2017
|
|
||
| return sd_bus_error_setf(error, SD_BUS_ERROR_NOT_SUPPORTED, | ||
| "Changing system settings via systemd is not supported on NixOS."); | ||
|
|
Member
Author
edolstra
pushed a commit
that referenced
this pull request
May 29, 2017
Fixes:
```
touch hola.service
systemctl link $(pwd)/hola.service $(pwd)/hola.service
```
```
==1==ERROR: AddressSanitizer: attempting double-free on 0x60300002c560 in thread T0 (systemd):
#0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00)
#1 0x7fc8c90ebd3b in strv_clear src/basic/strv.c:83
#2 0x7fc8c90ebdb6 in strv_free src/basic/strv.c:89
#3 0x55637c758c77 in strv_freep src/basic/strv.h:37
#4 0x55637c763ba9 in method_enable_unit_files_generic src/core/dbus-manager.c:1960
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
#20 0x55637c697339 in _start (/usr/lib/systemd/systemd+0xcd339)
0x60300002c560 is located 0 bytes inside of 19-byte region [0x60300002c560,0x60300002c573)
freed by thread T0 (systemd) here:
#0 0x7fc8c961cb00 in free (/lib64/libasan.so.3+0xc6b00)
#1 0x7fc8c90ee320 in strv_remove src/basic/strv.c:630
#2 0x7fc8c90ee190 in strv_uniq src/basic/strv.c:602
#3 0x7fc8c9180533 in unit_file_link src/shared/install.c:1996
#4 0x55637c763b25 in method_enable_unit_files_generic src/core/dbus-manager.c:1985
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
previously allocated by thread T0 (systemd) here:
#0 0x7fc8c95b0160 in strdup (/lib64/libasan.so.3+0x5a160)
#1 0x7fc8c90edf32 in strv_extend src/basic/strv.c:552
#2 0x7fc8c923ae41 in bus_message_read_strv_extend src/libsystemd/sd-bus/bus-message.c:5578
#3 0x7fc8c923b0de in sd_bus_message_read_strv src/libsystemd/sd-bus/bus-message.c:5600
#4 0x55637c7639d1 in method_enable_unit_files_generic src/core/dbus-manager.c:1969
#5 0x55637c763d16 in method_link_unit_files src/core/dbus-manager.c:2001
#6 0x7fc8c92537ec in method_callbacks_run src/libsystemd/sd-bus/bus-objects.c:418
#7 0x7fc8c9258830 in object_find_and_run src/libsystemd/sd-bus/bus-objects.c:1255
#8 0x7fc8c92594d7 in bus_process_object src/libsystemd/sd-bus/bus-objects.c:1371
#9 0x7fc8c91e7553 in process_message src/libsystemd/sd-bus/sd-bus.c:2563
#10 0x7fc8c91e78ce in process_running src/libsystemd/sd-bus/sd-bus.c:2605
#11 0x7fc8c91e8f61 in bus_process_internal src/libsystemd/sd-bus/sd-bus.c:2837
#12 0x7fc8c91e90d2 in sd_bus_process src/libsystemd/sd-bus/sd-bus.c:2856
#13 0x7fc8c91ea8f9 in io_callback src/libsystemd/sd-bus/sd-bus.c:3126
#14 0x7fc8c928333b in source_dispatch src/libsystemd/sd-event/sd-event.c:2268
#15 0x7fc8c9285cf7 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627
#16 0x7fc8c92865fa in sd_event_run src/libsystemd/sd-event/sd-event.c:2686
#17 0x55637c6b5257 in manager_loop src/core/manager.c:2274
#18 0x55637c6a2194 in main src/core/main.c:1920
#19 0x7fc8c7ac7400 in __libc_start_main (/lib64/libc.so.6+0x20400)
SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.3+0xc6b00) in free
==1==ABORTING
```
Closes systemd#5015
edolstra
pushed a commit
that referenced
this pull request
May 29, 2017
The simplest way to reproduce: ```diff diff --git a/src/libsystemd-network/test-dhcp6-client.c b/src/libsystemd-network/test-dhcp6-client.c index bd289fa..7b0a5ef 100644 --- a/src/libsystemd-network/test-dhcp6-client.c +++ b/src/libsystemd-network/test-dhcp6-client.c @@ -168,7 +168,7 @@ static uint8_t msg_advertise[198] = { 0x00, 0x17, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x18, 0x00, 0x0b, - 0x03, 0x6c, 0x61, 0x62, 0x05, 0x69, 0x6e, 0x74, + 0x01, 0x6c, 0x01, 0x62, 0x00, 0x0a, 0x6e, 0x74, 0x72, 0x61, 0x00, 0x00, 0x1f, 0x00, 0x10, 0x20, 0x01, 0x0d, 0xb8, 0xde, 0xad, 0xbe, 0xef, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, @@ -338,9 +338,7 @@ static int test_advertise_option(sd_event *e) { assert_se(!memcmp(addrs, &msg_advertise[124], r * 16)); r = sd_dhcp6_lease_get_domains(lease, &domains); - assert_se(r == 1); - assert_se(!strcmp("lab.intra", domains[0])); - assert_se(domains[1] == NULL); + assert_se(r == -ENOENT); r = sd_dhcp6_lease_get_ntp_addrs(lease, &addrs); assert_se(r == 1); ``` Fixes: ``` ================================================================= ==15043==ERROR: LeakSanitizer: detected memory leaks Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775774b95 in test_advertise_option src/libsystemd-network/test-dhcp6-client.c:287 #5 0x55f77577883e in main src/libsystemd-network/test-dhcp6-client.c:759 #6 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) Direct leak of 4 byte(s) in 1 object(s) allocated from: #0 0x7f13c8564160 in strdup (/lib64/libasan.so.3+0x5a160) #1 0x7f13c7caaf69 in strv_extend src/basic/strv.c:552 #2 0x55f775787230 in dhcp6_option_parse_domainname src/libsystemd-network/dhcp6-option.c:399 #3 0x55f775788b96 in dhcp6_lease_set_domains src/libsystemd-network/sd-dhcp6-lease.c:225 #4 0x55f775781348 in client_parse_message src/libsystemd-network/sd-dhcp6-client.c:807 #5 0x55f775781ba2 in client_receive_advertise src/libsystemd-network/sd-dhcp6-client.c:895 #6 0x55f775782453 in client_receive_message src/libsystemd-network/sd-dhcp6-client.c:994 #7 0x7f13c7e447f4 in source_dispatch src/libsystemd/sd-event/sd-event.c:2268 #8 0x7f13c7e471b0 in sd_event_dispatch src/libsystemd/sd-event/sd-event.c:2627 #9 0x7f13c7e47ab3 in sd_event_run src/libsystemd/sd-event/sd-event.c:2686 #10 0x7f13c7e47c21 in sd_event_loop src/libsystemd/sd-event/sd-event.c:2706 #11 0x55f77577863c in test_client_solicit src/libsystemd-network/test-dhcp6-client.c:737 #12 0x55f77577884b in main src/libsystemd-network/test-dhcp6-client.c:760 #13 0x7f13c7589400 in __libc_start_main (/lib64/libc.so.6+0x20400) SUMMARY: AddressSanitizer: 8 byte(s) leaked in 2 allocation(s). ```
Member
|
Thanks, pushed as In the interest of proper version management, let's not squash the timedated commit. |
Member
Author
|
It was not possible to open a pull request against nixos-v233 |
fpletz
pushed a commit
to mayflower/systemd
that referenced
this pull request
Feb 11, 2018
In general we'd leak anything that was allocated in the first parsing of
netdev, e.g. netdev name, host name, etc. Use normal netdev_unref to make sure
everything is freed.
--- command ---
/home/zbyszek/src/systemd/build2/test-network
--- stderr ---
/etc/systemd/network/wg0.netdev:3: Failed to parse netdev kind, ignoring: wireguard
/etc/systemd/network/wg0.netdev:5: Unknown section 'WireGuard'. Ignoring.
/etc/systemd/network/wg0.netdev:9: Unknown section 'WireGuardPeer'. Ignoring.
NetDev has no Kind configured in /etc/systemd/network/wg0.netdev. Ignoring
/etc/systemd/network/br0.network:13: Unknown lvalue 'NetDev' in section 'Network'
br0: netdev ready
=================================================================
==11666==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7f3a314cf238 in __interceptor_strdup (/lib64/libasan.so.4+0x77238)
NixOS#1 0x7f3a30e71ad1 in free_and_strdup ../src/basic/string-util.c:870
NixOS#2 0x7f3a30d34fba in config_parse_ifname ../src/shared/conf-parser.c:981
NixOS#3 0x7f3a30d2f5b0 in next_assignment ../src/shared/conf-parser.c:155
NixOS#4 0x7f3a30d30303 in parse_line ../src/shared/conf-parser.c:273
NixOS#5 0x7f3a30d30dee in config_parse ../src/shared/conf-parser.c:390
NixOS#6 0x7f3a30d310a5 in config_parse_many_files ../src/shared/conf-parser.c:428
NixOS#7 0x7f3a30d3181c in config_parse_many ../src/shared/conf-parser.c:487
NixOS#8 0x55b4200f9b00 in netdev_load_one ../src/network/netdev/netdev.c:634
NixOS#9 0x55b4200fb562 in netdev_load ../src/network/netdev/netdev.c:778
NixOS#10 0x55b4200c607a in manager_load_config ../src/network/networkd-manager.c:1299
NixOS#11 0x55b4200818e0 in test_load_config ../src/network/test-network.c:128
NixOS#12 0x55b42008343b in main ../src/network/test-network.c:254
NixOS#13 0x7f3a305f8889 in __libc_start_main (/lib64/libc.so.6+0x20889)
SUMMARY: AddressSanitizer: 4 byte(s) leaked in 1 allocation(s).
-------
fpletz
pushed a commit
that referenced
this pull request
Aug 3, 2018
Some versions of asan report the following false positive
when strict_string_checks=1 is passed:
=================================================================
==3297==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f64e4090286 bp 0x7ffe46acd9a0 sp 0x7ffe46acd118 T0)
==3297==The signal is caused by a READ memory access.
==3297==Hint: address points to the zero page.
#0 0x7f64e4090285 in __strlen_sse2 (/lib64/libc.so.6+0xaa285)
#1 0x7f64e5a51e46 (/lib64/libasan.so.4+0x41e46)
#2 0x7f64e4e5e3a0 (/lib64/libglib-2.0.so.0+0x383a0)
#3 0x7f64e4e5e536 in g_dgettext (/lib64/libglib-2.0.so.0+0x38536)
#4 0x7f64e48fac5f (/lib64/libgio-2.0.so.0+0xc1c5f)
#5 0x7f64e4c03978 in g_type_class_ref (/lib64/libgobject-2.0.so.0+0x30978)
#6 0x7f64e4be9567 in g_object_new_with_properties (/lib64/libgobject-2.0.so.0+0x16567)
#7 0x7f64e4be9fd0 in g_object_new (/lib64/libgobject-2.0.so.0+0x16fd0)
#8 0x7f64e48fd43e in g_dbus_message_new_from_blob (/lib64/libgio-2.0.so.0+0xc443e)
#9 0x564a6aa0de52 in main ../src/libsystemd/sd-bus/test-bus-marshal.c:228
#10 0x7f64e4007009 in __libc_start_main (/lib64/libc.so.6+0x21009)
#11 0x564a6aa0a569 in _start (/home/vagrant/systemd/build/test-bus-marshal+0x5569)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/lib64/libc.so.6+0xaa285) in __strlen_sse2
==3297==ABORTING
It's an external library and errors in external libraries are generally not very
useful for looking for internal bugs.
It would be better not to change the code and use standard suppression
techinques decribed at
https://clang.llvm.org/docs/AddressSanitizer.html#suppressing-reports-in-external-libraries,
but, unfortunaley, none of them seems to be able to suppress fatal errors in asan intself.
fpletz
pushed a commit
that referenced
this pull request
Aug 3, 2018
Fuzzing with AddressSanitizer reports an error here:
==11==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fe53f5497d8 at pc 0x7fe53ef055c9 bp 0x7ffd344e9380 sp 0x7ffd344e9378
READ of size 4 at 0x7fe53f5497d8 thread T0
SCARINESS: 27 (4-byte-read-global-buffer-overflow-far-from-bounds)
#0 0x7fe53ef055c8 in bus_error_name_to_errno /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24
#1 0x7fe53ef0577b in bus_error_setfv /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:274:17
#2 0x7fe53ef0595a in sd_bus_error_setf /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:284:21
#3 0x561059 in manager_load_unit_prepare /work/build/../../src/systemd/src/core/manager.c
#4 0x560680 in manager_load_unit /work/build/../../src/systemd/src/core/manager.c:1773:13
#5 0x5d49a6 in unit_add_dependency_by_name /work/build/../../src/systemd/src/core/unit.c:2882:13
#6 0x538996 in config_parse_unit_deps /work/build/../../src/systemd/src/core/load-fragment.c:152:21
#7 0x6db771 in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:155:32
#8 0x6d697e in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:273:16
#9 0x6d5c48 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:390:21
#10 0x535678 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-unit-file.c:41:16
#11 0x73bd60 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:517:13
#12 0x73a39f in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:442:3
#13 0x73d9bc in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:650:19
#14 0x73fa05 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:773:5
#15 0x71f75d in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:754:6
#16 0x71285c in main /src/libfuzzer/FuzzerMain.cpp:20:10
#17 0x7fe53da0482f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#18 0x430e68 in _start (/out/fuzz-unit-file+0x430e68)
0x7fe53f5497d8 is located 8 bytes to the right of global variable 'bus_common_errors' defined in '../../src/systemd/src/libsystemd/sd-bus/bus-common-errors.c:28:51' (0x7fe53f549300) of size 1232
SUMMARY: AddressSanitizer: global-buffer-overflow /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-error.c:118:24 in bus_error_name_to_errno
Shadow bytes around the buggy address:
0x0ffd27ea12a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea12e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0ffd27ea12f0: 00 00 00 00 00 00 00 00 00 00 f9[f9]f9 f9 f9 f9
0x0ffd27ea1300: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x0ffd27ea1310: f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9 f9
0x0ffd27ea1320: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea1330: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0ffd27ea1340: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==11==ABORTING
but I think it's a false positive because of our low-level magic in how this
area is constructed.
fpletz
pushed a commit
that referenced
this pull request
Aug 3, 2018
`fuzz-journal-remote` seems to be failing under `msan` as soon as it starts:
$ sudo infra/helper.py run_fuzzer systemd fuzz-journal-remote
Running: docker run --rm -i --privileged -e FUZZING_ENGINE=libfuzzer -v /home/vagrant/oss-fuzz/build/out/systemd:/out -t gcr.io/oss-fuzz-base/base-runner run_fuzzer fuzz-journal-remote
Using seed corpus: fuzz-journal-remote_seed_corpus.zip
/out/fuzz-journal-remote -rss_limit_mb=2048 -timeout=25 /tmp/fuzz-journal-remote_corpus -max_len=65536 < /dev/null
INFO: Seed: 3380449479
INFO: Loaded 2 modules (36336 inline 8-bit counters): 36139 [0x7ff36ea31d39, 0x7ff36ea3aa64), 197 [0x9998c8, 0x99998d),
INFO: Loaded 2 PC tables (36336 PCs): 36139 [0x7ff36ea3aa68,0x7ff36eac7d18), 197 [0x999990,0x99a5e0),
INFO: 2 files found in /tmp/fuzz-journal-remote_corpus
INFO: seed corpus: files: 2 min: 4657b max: 7790b total: 12447b rss: 97Mb
Uninitialized bytes in __interceptor_pwrite64 at offset 24 inside [0x7fffdd4d7230, 240)
==15==WARNING: MemorySanitizer: use-of-uninitialized-value
#0 0x7ff36e685e8a in journal_file_init_header /work/build/../../src/systemd/src/journal/journal-file.c:436:13
#1 0x7ff36e683a9d in journal_file_open /work/build/../../src/systemd/src/journal/journal-file.c:3333:21
#2 0x7ff36e68b8f6 in journal_file_open_reliably /work/build/../../src/systemd/src/journal/journal-file.c:3520:13
#3 0x4a3f35 in open_output /work/build/../../src/systemd/src/journal-remote/journal-remote.c:70:13
#4 0x4a34d0 in journal_remote_get_writer /work/build/../../src/systemd/src/journal-remote/journal-remote.c:136:21
#5 0x4a550f in get_source_for_fd /work/build/../../src/systemd/src/journal-remote/journal-remote.c:183:13
#6 0x4a46bd in journal_remote_add_source /work/build/../../src/systemd/src/journal-remote/journal-remote.c:235:13
#7 0x4a271c in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:36:9
#8 0x4f27cc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:524:13
#9 0x4efa0b in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:448:3
#10 0x4f8e96 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:732:7
#11 0x4f9f73 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:752:3
#12 0x4bf329 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:756:6
#13 0x4ac391 in main /src/libfuzzer/FuzzerMain.cpp:20:10
#14 0x7ff36d14982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#15 0x41f9d8 in _start (/out/fuzz-journal-remote+0x41f9d8)
Uninitialized value was stored to memory at
#0 0x7ff36e61cd41 in sd_id128_randomize /work/build/../../src/systemd/src/libsystemd/sd-id128/sd-id128.c:288:16
#1 0x7ff36e685cec in journal_file_init_header /work/build/../../src/systemd/src/journal/journal-file.c:426:13
#2 0x7ff36e683a9d in journal_file_open /work/build/../../src/systemd/src/journal/journal-file.c:3333:21
#3 0x7ff36e68b8f6 in journal_file_open_reliably /work/build/../../src/systemd/src/journal/journal-file.c:3520:13
#4 0x4a3f35 in open_output /work/build/../../src/systemd/src/journal-remote/journal-remote.c:70:13
#5 0x4a34d0 in journal_remote_get_writer /work/build/../../src/systemd/src/journal-remote/journal-remote.c:136:21
#6 0x4a550f in get_source_for_fd /work/build/../../src/systemd/src/journal-remote/journal-remote.c:183:13
#7 0x4a46bd in journal_remote_add_source /work/build/../../src/systemd/src/journal-remote/journal-remote.c:235:13
#8 0x4a271c in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:36:9
#9 0x4f27cc in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:524:13
#10 0x4efa0b in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:448:3
#11 0x4f8e96 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:732:7
#12 0x4f9f73 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:752:3
#13 0x4bf329 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:756:6
#14 0x4ac391 in main /src/libfuzzer/FuzzerMain.cpp:20:10
#15 0x7ff36d14982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Uninitialized value was created by an allocation of 't' in the stack frame of function 'sd_id128_randomize'
#0 0x7ff36e61cb00 in sd_id128_randomize /work/build/../../src/systemd/src/libsystemd/sd-id128/sd-id128.c:274
SUMMARY: MemorySanitizer: use-of-uninitialized-value /work/build/../../src/systemd/src/journal/journal-file.c:436:13 in journal_file_init_header
Exiting
MS: 0 ; base unit: 0000000000000000000000000000000000000000
artifact_prefix='./'; Test unit written to ./crash-847911777b3096783f4ee70a69ab6d28380c810b
[vagrant@localhost oss-fuzz]$ sudo infra/helper.py check_build --sanitizer=memory systemd
Running: docker run --rm -i --privileged -e FUZZING_ENGINE=libfuzzer -e SANITIZER=memory -v /home/vagrant/oss-fuzz/build/out/systemd:/out -t gcr.io/oss-fuzz-base/base-runner test_all
INFO: performing bad build checks for /out/fuzz-dhcp-server.
INFO: performing bad build checks for /out/fuzz-journal-remote.
INFO: performing bad build checks for /out/fuzz-unit-file.
INFO: performing bad build checks for /out/fuzz-dns-packet.
4 fuzzers total, 0 seem to be broken (0%).
Check build passed.
It's a false positive which is most likely caused by
google/sanitizers#852. I think it could be got around
by avoiding `getrandom` when the code is compiled with `msan`
Mic92
pushed a commit
that referenced
this pull request
Feb 22, 2019
This function returns 0 on success and a negative value on failure. On success,
it writes the parsed action to the address passed in its third argument.
`bus_set_transient_emergency_action` does this:
r = parse_emergency_action(s, system, &v);
if (v < 0)
// handle failure
However, `v` is not updated if the function fails, and this should be checking
`r` instead of `v`.
The result of this is that if an invalid failure (or success) action is
specified, systemd ends up creating the unit anyway and then misbehaves if it
tries to run the failure action because the action value comes from
uninitialized stack data. In my case, this resulted in a failed assertion:
Program received signal SIGABRT, Aborted.
0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6
(gdb) bt
#0 0x00007fe52cca0d7f in raise () from /snap/usr/lib/libc.so.6
#1 0x00007fe52cc8b672 in abort () from /snap/usr/lib/libc.so.6
#2 0x00007fe52d66f169 in log_assert_failed_realm (realm=LOG_REALM_SYSTEMD, text=0x56177ab8e000 "action < _EMERGENCY_ACTION_MAX", file=0x56177ab8dfb8 "../src/core/emergency-action.c", line=33, func=0x56177ab8e2b0 <__PRETTY_FUNCTION__.14207> "emergency_action") at ../src/basic/log.c:795
#3 0x000056177aa98cf4 in emergency_action (m=0x56177c992cb0, action=2059118610, options=(unknown: 0), reboot_arg=0x0, exit_status=1, reason=0x7ffdd2df4290 "unit run-u0.service failed") at ../src/core/emergency-action.c:33
#4 0x000056177ab2b739 in unit_notify (u=0x56177c9eb340, os=UNIT_ACTIVE, ns=UNIT_FAILED, flags=(unknown: 0)) at ../src/core/unit.c:2504
#5 0x000056177aaf62ed in service_set_state (s=0x56177c9eb340, state=SERVICE_FAILED) at ../src/core/service.c:1104
#6 0x000056177aaf8a29 in service_enter_dead (s=0x56177c9eb340, f=SERVICE_SUCCESS, allow_restart=true) at ../src/core/service.c:1712
#7 0x000056177aaf9233 in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1854
#8 0x000056177aaf921b in service_enter_signal (s=0x56177c9eb340, state=SERVICE_FINAL_SIGTERM, f=SERVICE_SUCCESS) at ../src/core/service.c:1852
#9 0x000056177aaf8eb3 in service_enter_stop_post (s=0x56177c9eb340, f=SERVICE_SUCCESS) at ../src/core/service.c:1788
#10 0x000056177aaf91eb in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGKILL, f=SERVICE_SUCCESS) at ../src/core/service.c:1850
#11 0x000056177aaf91bc in service_enter_signal (s=0x56177c9eb340, state=SERVICE_STOP_SIGTERM, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1848
#12 0x000056177aaf9759 in service_enter_running (s=0x56177c9eb340, f=SERVICE_FAILURE_EXIT_CODE) at ../src/core/service.c:1941
#13 0x000056177ab005b7 in service_sigchld_event (u=0x56177c9eb340, pid=112, code=1, status=1) at ../src/core/service.c:3296
#14 0x000056177aad84b5 in manager_invoke_sigchld_event (m=0x56177c992cb0, u=0x56177c9eb340, si=0x7ffdd2df48f0) at ../src/core/manager.c:2444
#15 0x000056177aad88df in manager_dispatch_sigchld (source=0x56177c994710, userdata=0x56177c992cb0) at ../src/core/manager.c:2508
#16 0x00007fe52d72f807 in source_dispatch (s=0x56177c994710) at ../src/libsystemd/sd-event/sd-event.c:2846
#17 0x00007fe52d730f7d in sd_event_dispatch (e=0x56177c993530) at ../src/libsystemd/sd-event/sd-event.c:3229
#18 0x00007fe52d73142e in sd_event_run (e=0x56177c993530, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3286
#19 0x000056177aad9f71 in manager_loop (m=0x56177c992cb0) at ../src/core/manager.c:2906
#20 0x000056177aa7c876 in invoke_main_loop (m=0x56177c992cb0, ret_reexecute=0x7ffdd2df4bff, ret_retval=0x7ffdd2df4c04, ret_shutdown_verb=0x7ffdd2df4c58, ret_fds=0x7ffdd2df4c70, ret_switch_root_dir=0x7ffdd2df4c48, ret_switch_root_init=0x7ffdd2df4c50, ret_error_message=0x7ffdd2df4c60) at ../src/core/main.c:1792
#21 0x000056177aa7f251 in main (argc=2, argv=0x7ffdd2df4e78) at ../src/core/main.c:2573
Fix this by checking the correct variable.
andir
pushed a commit
that referenced
this pull request
May 29, 2019
I had a test machine with ulimit -n set to 1073741816 through pam
("session required pam_limits.so set_all", which copies the limits from PID 1,
left over from testing of systemd#10921).
test-execute would "hang" and then fail with a timeout when running
exec-inaccessiblepaths-proc.service. It turns out that the problem was in
close_all_fds(), which would go to the fallback path of doing close()
1073741813 times. Let's just fail if we hit this case. This only matters
for cases where both /proc is inaccessible, and the *soft* limit has been
raised.
(gdb) bt
#0 0x00007f7e2e73fdc8 in close () from target:/lib64/libc.so.6
#1 0x00007f7e2e42cdfd in close_nointr ()
from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
#2 0x00007f7e2e42d525 in close_all_fds ()
from target:/home/zbyszek/src/systemd-work3/build-rawhide/src/shared/libsystemd-shared-241.so
#3 0x0000000000426e53 in exec_child ()
#4 0x0000000000429578 in exec_spawn ()
#5 0x00000000004ce1ab in service_spawn ()
#6 0x00000000004cff77 in service_enter_start ()
#7 0x00000000004d028f in service_enter_start_pre ()
#8 0x00000000004d16f2 in service_start ()
#9 0x00000000004568f4 in unit_start ()
#10 0x0000000000416987 in test ()
#11 0x0000000000417632 in test_exec_inaccessiblepaths ()
#12 0x0000000000419362 in run_tests ()
#13 0x0000000000419632 in main ()
andir
pushed a commit
that referenced
this pull request
Sep 7, 2019
We would not send the property because we'd call sd_bus_get_current_message() which would return NULL. If there is no message, we cannot support /self or /auto, but things are still OK if a path with a session name is given. Traceback when the issue is triggered: #2 we'd call sd_bus_get_current_message() here, which would return NULL, and session_object_find() would immediately return 0. #3 0x00000000004289b7 in session_object_find (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x9efda0 "org.freedesktop.login1.Session", userdata=0x9852f0, found=0x7ffe3e975fe8, error=0x7ffe3e9760b0) at ../src/login/logind-session-dbus.c:620 #4 0x00007ff74bfdde39 in node_vtable_get_userdata (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", c=0x9f6d58, userdata=0x7ffe3e976070, error=0x7ffe3e9760b0) at ../src/libsystemd/sd-bus/bus-objects.c:37 #5 0x00007ff74bfe49af in emit_properties_changed_on_interface (bus=0x9f1110, prefix=0xa133a0 "/org/freedesktop/login1/session", path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", require_fallback=true, found_interface=0x7ffe3e976163, names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2088 #6 0x00007ff74bfe56a4 in sd_bus_emit_properties_changed_strv (bus=0x9f1110, path=0xa160b0 "/org/freedesktop/login1/session/c2", interface=0x43f9f8 "org.freedesktop.login1.Session", names=0x7ffe3e9761b0) at ../src/libsystemd/sd-bus/bus-objects.c:2291 #7 0x00000000004292ea in session_send_changed (s=0xa16e10, properties=0x43ee27 "Active") at ../src/login/logind-session-dbus.c:730 #8 0x0000000000424cd7 in seat_set_active (s=0x9ee280, session=0xa16e10) at ../src/login/logind-seat.c:249 #9 0x00000000004251cf in seat_active_vt_changed (s=0x9ee280, vtnr=3) at ../src/login/logind-seat.c:361 #10 0x000000000042547b in seat_read_active_vt (s=0x9ee280) at ../src/login/logind-seat.c:395 #11 0x000000000040ab5c in manager_dispatch_console (s=0x9f0320, fd=8, revents=8, userdata=0x9852f0) at ../src/login/logind.c:588 #12 0x00007ff74c042d5f in source_dispatch (s=0x9f0320) at ../src/libsystemd/sd-event/sd-event.c:2828 #13 0x00007ff74c04469f in sd_event_dispatch (e=0x9ef340) at ../src/libsystemd/sd-event/sd-event.c:3241 #14 0x00007ff74c044b58 in sd_event_run (e=0x9ef340, timeout=18446744073709551615) at ../src/libsystemd/sd-event/sd-event.c:3299 #15 0x000000000040d7e8 in manager_run (m=0x9852f0) at ../src/login/logind.c:1186 #16 0x000000000040db58 in run (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1234 #17 0x000000000040dc30 in main (argc=1, argv=0x7ffe3e976728) at ../src/login/logind.c:1244 Fixes systemd#13437. Bug introduced in 3b92c08.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
NEWS
Upgrade was pretty smooth. One notably change is the new hybrid cgroup mode: https://github.com/systemd/systemd/blob/v233/NEWS#L5 It should provide better compatibility with docker.
Tested with: