This lets the libc/xcrypt allocate as much storage area as it needs.
Should fix#16965:
testsuite-46.sh[74]: ==74==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f3e972e1080 at pc 0x7f3e9be8deed bp 0x7ffce4f28530 sp 0x7ffce4f27ce0
testsuite-46.sh[74]: WRITE of size 131232 at 0x7f3e972e1080 thread T0
testsuite-46.sh[74]: #0 0x7f3e9be8deec (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec)
testsuite-46.sh[74]: #1 0x559cd05a6412 in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:818:21
testsuite-46.sh[74]: #2 0x559cd058fb03 in create_home /systemd-meson-build/../build/src/home/homectl.c:1112:29
testsuite-46.sh[74]: #3 0x7f3e9b5b3058 in dispatch_verb /systemd-meson-build/../build/src/shared/verbs.c:103:24
testsuite-46.sh[74]: #4 0x559cd058c101 in run /systemd-meson-build/../build/src/home/homectl.c:3325:16
testsuite-46.sh[74]: #5 0x559cd058c00a in main /systemd-meson-build/../build/src/home/homectl.c:3328:1
testsuite-46.sh[74]: #6 0x7f3e9a88b151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
testsuite-46.sh[74]: #7 0x559cd0583e7d in _start (/usr/bin/homectl+0x24e7d)
testsuite-46.sh[74]: Address 0x7f3e972e1080 is located in stack of thread T0 at offset 32896 in frame
testsuite-46.sh[74]: #0 0x559cd05a60df in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:789
testsuite-46.sh[74]: This frame has 6 object(s):
testsuite-46.sh[74]: [32, 40) 'priv' (line 790)
testsuite-46.sh[74]: [64, 72) 'np' (line 791)
testsuite-46.sh[74]: [96, 104) 'salt' (line 809)
testsuite-46.sh[74]: [128, 32896) 'cd' (line 810)
testsuite-46.sh[74]: [33152, 33168) '.compoundliteral' <== Memory access at offset 32896 partially underflows this variable
testsuite-46.sh[74]: [33184, 33192) 'new_array' (line 832) <== Memory access at offset 32896 partially underflows this variable
testsuite-46.sh[74]: HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
testsuite-46.sh[74]: (longjmp and C++ exceptions *are* supported)
testsuite-46.sh[74]: SUMMARY: AddressSanitizer: stack-buffer-overflow (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec)
It seems 'struct crypt_data' is 32896 bytes, but libclang_rt wants more, at least 33168?
Mention the JSON user record stuff. Mention pam_umask explicitly.
Mention that UMask= of the per-user user@.service instance can be used
too.
Fixes: #16963
Like it's customary in our codebase bus_error_message() internally takes
abs() of the passed error anyway, hence no need to explicitly negate it.
We mostly got this right, but in too many cases we didn't. Fix that.
We already do this for socket and automount units, do it for path units
too: if the triggered service keeps hitting the start limit, then fail
the triggering unit too, so that we don#t busy loop forever.
(Note that this leaves only timer units out in the cold for this kind of
protection, but it shouldn't matter there, as they are naturally
protected against busy loops: they are scheduled by time anyway).
Fixes: #16669
In 4c2ef32767 we enabled propagating
triggered unit state to the triggering unit for service units in more
load states, so that we don't accidentally stop tracking state
correctly.
Do the same for our other triggering unit states: automounts, paths, and
timers.
Also, make this an assertion rather than a simple test. After all it
should never happen that we get called for half-loaded units or units of
the wrong type. The load routines should already have made this
impossible.
In shell, inside of double quotes only a select few chars should be
escaped. If other chars are escaped this has no effect. Correct the list
of chars that need such escaping.
Also, make sure we can read back the stuff we wrote out without loss.
Fixes: #16788
We want to be able to use BusName= in services that run during early boot
already, and thus don't synthesize deps on dbus there. Instead add them
when Type=dbus is set, because in that case we actually really need
D-Bus support.
Fixes: #17037
Symbolic names and number in the appropriate range are allowed
(log_level_from_string() DTRT already).
The target names are more messy, so we leave the verification to the service.
Heavily inspired by #15622. This adds:
systemctl service-log-level systemd-resolved
systemctl service-log-level systemd-resolved info
systemctl service-log-target systemd-resolved
systemctl service-log-target systemd-resolved console
We already have systemctl verbs log-level, log-target, and service-watchdogs.
Those two new verbs tie nicely into this scheme.
if we allocate a bunch of hash tables all at the same time, with none
earlier than the other, there's a good chance we'll initialize the
shared hash key multiple times, so that some threads will see a
different shared hash key than others.
Let's fix that, and make sure really everyone sees the same hash key.
Fixes: #17007
In containers we might lack the privs to up the socket buffers. Let's
not complain so loudly about that. Let's hence downgrade this to debug
logging if it's a permission problem.
(This wasn't an issue before b92f350789
because back then the failures wouldn't be detected at all.)
Previously we would call umount from ExecStartPost= of
systemd-cryptsetup instance in order to get rid of the keydev
mount (i.e. filesystem containing keyfile). Let's generate unit to
handle umount. Making this symmetrical (both mount and umount of keydev
are handled by units) fixes the problem with lingering keydev mounts.
Motivation for the change is the issue where keydev mount would stay
around even if device was successfully unlocked and mount is no longer
needed. That could happen previously because when generator options are
not prefixed with "rd." we run generators twice (e.g. rd.luks.key=...).
In such case disk is unlocked in initramfs phase of boot (assuming the
initrd image contains the generator and is able to handle unlocking of
LUKS devices). After switchroot we however enqueue start job for
systemd-cryptsetup instance (because units are regenerated second time)
and that pulls in its dependencies into transaction. Later the main
systemd-cryptsetup unit not actually started since it is already active
and has RemainaAfterExit=yes. Nevertheless, dependencies get activated
and keydev mount is attached again. Because previously we called umount
from ExecStartPost= of systemd-cryptsetup instance the umount is not
called second time and keydev filesystem stays lingering.
Otherwise our request will possibly fail if something else is already
enqeued, but given this is an explicit user request, let's not allow
things to fail.
Fixes: #16702
The manual states that a persistent timer triggers it's service
immediately on activation to catch up with missed invocations, but since
PR #11608 it is no longer the case if RandomizedDelaySec= is set to a
non-zero value.
Zbigniew Jędrzejewski-Szmek