ASan is having a hard time to get its LD_PRELOAD= shenanigans straight
with all the shells flying around. Let's make it a bit easier by using
one of the nifty systemctl's features instead.
so we can run TEST-46 under sanitizers once again.
`systemd-homed` runs fsck on home directories, which reports a memory
leak we're not interested in. Let's introduce an LSan suppression file
to get around this. Since the patterns in the suppression file are
matched using basic substring match[0], they're a bit cumbersome, but
should get the work one.
[0] https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions
Example leaks (as reported by TEST-46):
```
systemd-homed[1333]: =================================================================
systemd-homed[1333]: ==1333==ERROR: LeakSanitizer: detected memory leaks
systemd-homed[1333]: Direct leak of 24 byte(s) in 1 object(s) allocated from:
systemd-homed[1333]: #0 0x7f0c8facccd1 in calloc (/usr/lib/clang/12.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xf4cd1)
systemd-homed[1333]: #1 0x558d9494ff67 (/usr/bin/fsck+0x3f67)
systemd-homed[1333]: Direct leak of 6 byte(s) in 1 object(s) allocated from:
systemd-homed[1333]: #0 0x7f0c8fa906c1 in strdup (/usr/lib/clang/12.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xb86c1)
systemd-homed[1333]: #1 0x558d949518fd (/usr/bin/fsck+0x58fd)
systemd-homed[1333]: SUMMARY: AddressSanitizer: 30 byte(s) leaked in 2 allocation(s).
systemd-homed[1337]: ==1337==WARNING: Symbolizer was blocked from starting itself!
systemd-homed[1337]: =================================================================
systemd-homed[1337]: ==1337==ERROR: LeakSanitizer: detected memory leaks
systemd-homed[1337]: Direct leak of 67584 byte(s) in 1 object(s) allocated from:
systemd-homed[1337]: #0 0x7f01edb84b19 (/usr/lib/clang/12.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xf4b19)
systemd-homed[1337]: #1 0x7f01e8326829 (/usr/bin/../lib/libLLVM-12.so+0xb46829)
systemd-homed[1337]: SUMMARY: AddressSanitizer: 67584 byte(s) leaked in 1 allocation(s).
```
With the suppression file:
```
systemd-homed[1339]: -----------------------------------------------------
systemd-homed[1339]: Suppressions used:
systemd-homed[1339]: count bytes template
systemd-homed[1339]: 2 30 /bin/fsck$
systemd-homed[1339]: -----------------------------------------------------
systemd-homed[1343]: ==1343==WARNING: Symbolizer was blocked from starting itself!
systemd-homed[1343]: -----------------------------------------------------
systemd-homed[1343]: Suppressions used:
systemd-homed[1343]: count bytes template
systemd-homed[1343]: 1 67584 /lib/libLLVM
systemd-homed[1343]: -----------------------------------------------------
```
veritysetup-generator, fstab-generator: Setup and mount usr verity device when 'usrhash' (and optionally systemd.verity_usr_*) is present as kernel command line parameter
* man: document FIDO2 device removal
Indicate to users how to remove FIDO2 device in the --fido2-device=path section by setting path to an empty string (""). Tested on systemd 249 (249.6-3-arch)
Since 8b8024f1c2 and the follow-up commits, the
main config file may be located in /usr or in other paths. But the code in
analyze.c was still assuming that it must be in /etc. Things mostly worked for
our own config files because we usually install a comments-only file in /etc,
but was not correct in the general case.
This fixes in particular 'systemd-analyze cat-config systemd/zram-generator.conf'.
In Fedora we distribute a config file in zram-generator-defaults.rpm that is in
/usr/lib, and 'cat-config' would refuse to show it because
/etc/systemd/zram-generator.conf does not exist.
The main config file is optional, but let's print an informative message
because this is a slightly unusual case.
The file paths that we printed were missing the root prefix.
The function name `method_reload` is used both in dbus-unit.c and
dbus-manager.c for static functions.
With the previous addition of adding the function name to the audit
information on SELinux denials, rename the one (and its relatives) in
dbus-unit.c as most of the functions in src/core/dbus-unit.c are already
prefixed with `bus_unit_`.
`mac_selinux_generic_access_check()` should not be called directly, only
via the wrapper macros `mac_selinux_access_check` and
`mac_selinux_unit_access_check`.
path might be NULL when checking against the system permissions, so wrap
with strna().
The command line might not be available over D-Bus and thus cl might be
empty. Print "n/a" instead of the empty string.
Include the systemd C function name in the audit message to improve the
debug ability on denials.
Similar like kernel denial messages include the syscall name.
MMapFileDescriptor carries a reference to its originating
MMapCache, there's no value in supplying the
MMapFileDescriptor-centric functions a separate MMapCache.
A future commit will rename these functions to consistently use
an mmap_cache_fd_* prefix for improved clarity.
4e76715489 added a slightly different UUID
in the header and in the docs. This makes the code match the docs.
> As some downstream projects are already using the UUID as in the docs, most
> notably util-linux [1], we should adjust code to match doc; no shipping
> LoongArch systems are using upstream systemd, and no open-source distro is
> merging LoongArch support yet, so the change should break no one. This also
> matches the work being done by @yetist at loongarch64/systemd#7.
[1] https://github.com/util-linux/util-linux/commit/2d29fccaad267d1b003dc0ed2bb9634ff76f3e49
This adds a helper script:
$ python3 tools/list-discoverable-partitions.py <src/shared/gpt.h
<!-- generated with tools/list-discoverable-partitions.py -->
| Partition Type UUID | Name | Allowed File Systems | Explanation |
|---------------------|------|----------------------|-------------|
| _Root Partition (Alpha)_ | `6523f8ae-3eb1-4e2a-a05a-18b695ae656f` | [Root Partition] | [Root Partition more] |
| _Root Partition (ARC)_ | `d27f46ed-2919-4cb8-bd25-9531f3c16534` | ditto | ditto |
...
The output can be pasted into the markdown file. I think this works better than
trying to match the two lists by hand.
I don't think we want people to send us pull requests over the next two years.
Let's just make something up ourselves, this is going to have at least as good
results, and will be much quicker.
Note that this only includes architectures for which there's some indication
that they are in active use. In architecture.h there are some more esoteric
ones like ARC_BE. We can add those if there's some actual user demand.
In particular, I included everything on the Debian "List of official ports" [1]
and a few other arches that we have received patches for in recent times.
[1] https://www.debian.org/ports/#portlist-released
The existing verify_hash_table() function is renamed to
verify_data_hash_table() since it only verifies the data hash table.
The verify information is also made a little more detailed by splitting
one of the checks in two.
https://wiki.debian.org/ArchitectureSpecificsMemo shows the triplet, but no the
linker paths. I used the linker path from Fedora.
$ ls -l /lib /lib64
lrwxrwxrwx. 1 root root 7 Aug 13 2020 /lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Aug 13 2020 /lib64 -> usr/lib64
$ ldd /bin/sh|grep ld
/lib/ld-linux-riscv64-lp64d.so.1 (0x0000003fb8185000)
$ ls -l /lib/ld-linux-riscv64-lp64d.so.1
lrwxrwxrwx 1 root root 19 Aug 4 19:28 /lib/ld-linux-riscv64-lp64d.so.1 -> ../lib64/ld-2.32.so
$ uname -r
5.10.6+
So even though the canonical linker path uses /lib/, we need the /lib64 symlink
to be present.
https://wiki.debian.org/ArchitectureSpecificsMemo shows the triplet, but no the
linker paths. I used the linker path from Fedora, but I can't look up the
linker paths for BE and 32 bit. At least the ifdef scaffolding is provided, so
it should be trivial to fill in if somebody has access to such a system.
$ ls -l /lib /lib64
lrwxrwxrwx. 1 root root 7 Jan 26 2021 /lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jan 26 2021 /lib64 -> usr/lib64
$ ldd /bin/sh|grep ld
/lib64/ld64.so.2 (0x00007fffa0a90000)
$ uname -r
5.14.9-200.fc34.ppc64le
Note that the macro defines listed in the wiki page don't match what I get
on Fedora: __PPC64__ vs. __ppc64__.
$ cpp -dM < /dev/null |grep -iE '__(powerpc|ppc)'|sort
#define __powerpc__ 1
#define __powerpc64__ 1
#define __PPC__ 1
#define __PPC64__ 1
First half of the fix for #14311.
Lennart Poettering
Frantisek Sumsal
Jan Janssen
Andy Chi
Luca Boccassi
Robert-L-Turner
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Christian Göttsche
Vito Caputo
Mark Boudreau