If an entry in fstab uses "x-systemd.automount" option and also asks for
additionnal dependencies via x-systemd.requires or such, then the dependencies
were applied to the automount unit.
But this unlikely to do the right thing and is inconsistent with what's done
for network mounts.
Indeed when an fstab entries has "_netdev,x-systemd.automount" options, the
dependencies against the network requested by "_netdev" are (correctly) applied
to the mount unit only and the automount unit remains ordered against
local-fs.target.
The same logic should be followed when extra deps are specified via the mount
options as automount units should always be ordered against local-fs.target.
Note: in general explicit deps specified via mount options should be used with
care and should be used to specify dependencies on other mount units only as it
can easily create ordering cycles otherwise like it's been seen in
https://github.com/systemd/systemd-stable/issues/69. Mount units (as well as
automount ones) are ordered before local-fs.target by default which is a
low-level target that most other units depend on.
There's some highly specific PKCS#11 code in homectl.c. Let's split that
out, since it is easily isolatable, to make homectl.c a bit more
readable.
No funcional changes, just some moving around and renaming two functions
to make them more suitably named when exported.
When updating a home directory we might update the record first, then
resize the image and finally synchronize the passwords to the storage
layers. These are three individually authenticated operations. Since
each might require touching a FIDO2 or PKCS#11 key we should say what we
are doing. Hence do so.
Usually we are pretty quiet with what we do, and let's stick to that.
Hence show this information only if we actually do more than one thing.
If we only update (and do not resize/sync passwords) then let's be quiet
as usual, as the command line then sufficiently clarifies what we are
doing.
After all, when creating we might need interaction with the security
token too, and our initial attempt to create the user will fail, since
we do not allow interactive auth on the security token, so that we then
can print a log message and retry with interactive auth then enabled.
We'd like to use it for FIDO2 tokens too, and the concept is entirely
generic, hence let's just reuse the field, but rename it. Read the old
name for compatibility, and treat the old name and the new name as
identical for most purposes.
SR-IOV provides the ability to partition a single physical PCI
resource into virtual PCI functions which can then be injected in
to a VM. In the case of network VFs, SR-IOV improves north-south n
etwork performance (that is, traffic with endpoints outside the
host machine) by allowing traffic to bypass the host machine’s network stack.
All devices behind a SPI controller have the same udev ID_PATH property.
This is a problem for predicable network names for CAN controllers.
CAN controllers, in contrast to Ethernet controllers, don't have a MAC
Address, so there's no way to tell two CAN controllers on the same SPI
host controller apart:
$ udevadm info /sys/class/net/can0
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
E: INTERFACE=can0
E: IFINDEX=3
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11187199
E: ID_PATH=platform-fe204000.spi
E: ID_PATH_TAG=platform-fe204000_spi
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can0
E: TAGS=:systemd:
$ udevadm info /sys/class/net/can1
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
E: INTERFACE=can1
E: IFINDEX=4
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11192211
E: ID_PATH=platform-fe204000.spi
E: ID_PATH_TAG=platform-fe204000_spi
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can1
E: TAGS=:systemd:
With this the chip select number is added to the ID_PATH, to make
predictable network names possible.
$ sudo udevadm info /sys/class/net/can0
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.1/net/can0
E: INTERFACE=can0
E: IFINDEX=3
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11187199
E: ID_PATH=platform-fe204000.spi-cs-1
E: ID_PATH_TAG=platform-fe204000_spi-cs-1
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can0
E: TAGS=:systemd:
$ sudo udevadm info /sys/class/net/can1
P: /devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
L: 0
E: DEVPATH=/devices/platform/soc/fe204000.spi/spi_master/spi0/spi0.0/net/can1
E: INTERFACE=can1
E: IFINDEX=4
E: SUBSYSTEM=net
E: USEC_INITIALIZED=11192211
E: ID_PATH=platform-fe204000.spi-cs-0
E: ID_PATH_TAG=platform-fe204000_spi-cs-0
E: SYSTEMD_ALIAS=/sys/subsystem/net/devices/can1
E: TAGS=:systemd:
When the system is under heavy load, it can happen that the unit cache
is refreshed for an unrelated reason (in the test I simulate this by
attempting to start a non-existing unit). The new unit is found and
accounted for in the cache, but it's ignored since we are loading
something else.
When we actually look for it, by attempting to start it, the cache is
up to date so no refresh happens, and starting fails although we have
it loaded in the cache.
When the unit state is set to UNIT_NOT_FOUND, mark the timestamp in
u->fragment_loadtime. Then when attempting to load again we can check
both if the cache itself needs a refresh, OR if it was refreshed AFTER
the last failed attempt that resulted in the state being
UNIT_NOT_FOUND.
Update the test so that this issue reproduces more often.
../src/shared/efi-loader.c:738:5: error: redefinition of 'efi_loader_get_config_timeout_one_shot'
int efi_loader_get_config_timeout_one_shot(usec_t *ret) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/shared/efi-loader.c:9:
../src/shared/efi-loader.h:85:19: note: previous definition of 'efi_loader_get_config_timeout_one_shot' was here
static inline int efi_loader_get_config_timeout_one_shot(usec_t *ret) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/shared/efi-loader.c:776:5: error: redefinition of 'efi_loader_update_entry_one_shot_cache'
int efi_loader_update_entry_one_shot_cache(char **cache, struct stat *cache_stat) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/shared/efi-loader.c:9:
../src/shared/efi-loader.h:89:19: note: previous definition of 'efi_loader_update_entry_one_shot_cache' was here
static inline int efi_loader_update_entry_one_shot_cache(char **cache, struct stat *cache_stat) {
To set up a verity/cryptsetup RootImage the forked child needs to
ioctl /dev/mapper/control and create a new mapper.
If PrivateDevices=yes and/or DevicePolicy=closed are used, this is
blocked by the cgroup setting, so add an exception like it's done
for loop devices (and also add a dependency on the kernel modules
implementing them).
With this we are now caching all EFI variables that we expose as
property in logind. Thus a client invoking GetAllProperties() should
only trgger a single read of each variable, but never repeated ones.
Obsoletes: #16190Fixes: #14828
The data from this EFI variable is exposed as dbus property, and gdbus
clients are happy to issue GetAllProperties() as if it was free. Hence
make sure it's actually free and cache LoaderConfigTimeoutOneShot, since
it's easy.
This allows copying in arbitrary file systems on the block level into
newly created partitions.
Usecase: simple replicating OS installers or OS image builders.
open_tmpfile_linkable is used to create a temporary file in the same
directory as the target, but portabled uses the name of the parent
directory instead of the file it intends to create.
In other words, it creats a tmp for /etc/systemd/system.attached instead
of /etc/systemd/system.attached/foo.service.
It still works because it's later moved in the right place.
But as a side effect, it tries the create the file in the parent directory
which is /etc/systemd, and it case of read-only filesystems it fails.
Since bc8d57f290 mac_selinux_init() is checked and considered fatal
tree-wide.
Coverity complains about it not being checked in the test code.
Follow-up of: #16223
Fixes: CID 1429975
Even with the new keyed hash table journal feature: if an attacker
manages to get access to the journal file id it could synthesize records
that result in hash collisions. Let's rotate automatically when we
notice that, so that a new journal file ID is generated, our performance
is restored and the attacker has to guess a new file ID before being
able to trigger the issue again.
That said, untrusted peers should never get access to journal files in
the first case...
This adds a new (incompatible) feature to journal files: if enabled the
hash function used for the hash tables is no longer jenkins hash with a
zero key, but siphash keyed by the file uuid that is included in the
file header anyway. This should make our hash tables more robust against
collision attacks, as long as the attacker has no read access to the
journal files. We switch from jenkins to siphash simply because it's
more well-known and we standardize for the rest of our codebase onto it.
This is hardening in order to make collision attacks harder for clients
that can forge log messages but have no read access to the logs. It has
no effect on clients that have read access.
Let's prefix this with "jenkins_" since it wraps the jenkins hash. We
want to add support for other hash functions to journald soon, hence
better be clear with what this is. In particular as all other symbols
defined by lookup3.h actually are prefixed "jenkins_".
Let's clean this up a bit, following our usual nomenclature to name
return parameters ret-xyz.
This is mostly a bit of renaming, but there's also some minor other
changes: if we return a pointer to a mmap'ed object plus its offset, in
almost all cases we are happy if either parameter is NULL in case the
caller is not interested in it. Let's fix the remaining case to do this
too, to minimize surprises.
The object flags field is a bitmask, hence don't sloppily define
_OBJECT_COMPRESSED_MAX as one mor than the previous flag. That worked OK
as long as we only had two flags, but will fall apart as soon as we have
three. Let's fix this.
(It's kinda sloppy how the string table is built here, as it will be
quite sparse as soon as we have more enum entries, but let's keep it for
now.)
Instead of reading these files at startup and never again, let's read
them when we need them. As an optimization (in particular as some of
these files contain the data for many fields at once) let's cache the
results as long as the stat data (i.e. mtime) remains stable.
Also, while we are at it, if we can't read any of these props, let's not
fail everything, but continue without the data.
Since cryptsetup 2.3.0 a new API to verify dm-verity volumes by a
pkcs7 signature, with the public key in the kernel keyring,
is available. Use it if libcryptsetup supports it.
Since cryptsetup 2.3.0 a new API to verify dm-verity volumes by a
pkcs7 signature, with the public key in the kernel keyring,
is available. Use it if libcryptsetup supports it in the
veritysetup helper binary.
https://tools.ietf.org/html/draft-knodel-terminology-02https://lwn.net/Articles/823224/
This gets rid of most but not occasions of these loaded terms:
1. scsi_id and friends are something that is supposed to be removed from
our tree (see #7594)
2. The test suite defines an API used by the ubuntu CI. We can remove
this too later, but this needs to be done in sync with the ubuntu CI.
3. In some cases the terms are part of APIs we call or where we expose
concepts the kernel names the way it names them. (In particular all
remaining uses of the word "slave" in our codebase are like this,
it's used by the POSIX PTY layer, by the network subsystem, the mount
API and the block device subsystem). Getting rid of the term in these
contexts would mean doing some major fixes of the kernel ABI first.
Regarding the replacements: when whitelist/blacklist is used as noun we
replace with with allow list/deny list, and when used as verb with
allow-list/deny-list.
This fixes commit db2b8d2e28 that
rectified parsing empty values but broke parsing explicit infinity.
Intended parsing semantics will be captured in a testcase in a follow up
commit.
Ref: #16248
Presently, CLI utilities such as systemctl will check whether they have a tty
attached or not to decide whether to parse /proc/cmdline or EFI variable
SystemdOptions looking for systemd.log_* entries.
But this check will be misleading if these tools are being launched by a
daemon, such as a monitoring daemon or automation service that runs in
background.
Make log handling of CLI tools uniform by never checking /proc/cmdline or EFI
variables to determine the logging level.
Furthermore, introduce a new log_setup_cli() shortcut to set up common options
used by most command-line utilities.
Also use double space before the tracking args at the end. Without
the comma this looks ugly, but it's a bit better with the double space.
At least it doesn't look like a variable with a type.
I'm not sure if I understand the code correctly, but it seems that if
storig in the second set failed, we'd return with the first set having
no reference on the link object, and the link object could be freed in the
future, leaving the set with a dangling reference.
On error, we'd just free the object, and not close the fd.
While at it, let's use set_ensure_consume() to make sure we don't leak
the object if it was already in the set. I'm not sure if that condition
can be achieved.
_cleanup_set_free_ is enough for unit_files, because unit_files is
allocated in set_put_strdup(), which uses string_hash_ops_free.
This fixes a leak if marker was already present in the table.
This combines set_ensure_allocated() with set_consume(). The cool thing is that
because we know the hash ops, we can correctly free the item if appropriate.
Similarly to set_consume(), the goal is to simplify handling of the case where
the item needs to be freed on error and if already present in the set.
* Drop mac_selinux_use() condition from mac_selinux_free(): if the
passed pointer holds memory we want to free it even if SELinux is
disabled
* Drop NULL-check cause man:freecon(3) states that freecon(NULL) is a
well-defined NOP
* Assert that on non-SELinux builds the passed pointer is always NULL,
to avoid memory leaks
Previously we'd used the existance of a specific AF_UNIX socket in the
abstract namespace as lock for disabling lookup recursions. (for
breaking out of the loop: userdb synthesized from nss → nss synthesized
from userdb → userdb synthesized from nss → …)
I did it like that because it promised to work the same both in static
and in dynmically linked environments and is accessible easily from any
programming language.
However, it has a weakness regarding reuse attacks: the socket is
securely hashed (siphash) from the thread ID in combination with the
AT_RANDOM secret. Thus it should not be guessable from an attacker in
advance. That's only true if a thread takes the lock only once and
keeps it forever. However, if a thread takes and releases it multiple
times an attacker might monitor that and quickly take the lock
after the first iteration for follow-up iterations.
It's not a big issue given that userdb (as the primary user for this)
never released the lock and we never made the concept a public
interface, and it was only included in one release so far, but it's
something that deserves fixing. (moreover it's a local DoS only, only
permitting to disable native userdb lookups)
With this rework the libnss_systemd.so.2 module will now export two
additional symbols. These symbols are not used by glibc, but can be used
by arbitrary programs: one can be used to disable nss-systemd, the other
to check if it is currently disabled.
The lock is per-thread. It's slightly less pretty, since it requires
people to manually link against C code via dlopen()/dlsym(), but it
should work safely without the aforementioned weakness.
This just adds a _cleanup_ helper call encapsulating dlclose().
This also means libsystemd-shared is linked against libdl now. I don't
think this is much of an issue, since libdl is part of glibc anyway, and
anything from exotic. It's not an optional part of the OS (think: NSS
requires dynamic linking), hence this pulls in no deps and is almost
certainly loaded into all process' memory anyway.
[zj: use DEFINE_TRIVIAL_CLEANUP_FUNC().]
This reverts commit 53aa85af24.
The reason is that that patch changes the dbus api to be different than
the types declared by introspection api.
Replaces #16122.
This reverts commit 097537f07a.
At least Fedora and Debian have already reverted this at the distro
level because it causes more problems than it solves. Arch is debating
reverting it as well [0] but would strongly prefer that this happens
upstream first. Fixes#15188.
[0] https://bugs.archlinux.org/task/66458
If an autostart file for GNOME has a phase specified, then this implies
it is a session service that needs to be started at a specific time.
We have no way of handling the ordering, and while it does make sense
to explicitly hide these services with X-systemd-skip, there is no point
in even trying to handle them.
Since #15533 we didn't create the mount point for selinuxfs anymore.
Before it we created it twice because we mount selinuxfs twice: once the
superblock, and once we remount its bind mound read-only. The second
mkdir would mean we'd chown() the host version of selinuxfs (since
there's only one selinuxfs superblock kernel-wide).
The right time to create mount point point is once: before we mount the
selinuxfs. But not a second time for the remount.
Fixes: #16032
We'd try to map a zero-byte buffer from a NULL pointer, which is undefined behaviour.
src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60: runtime error: applying zero offset to null pointer
#0 0x7f6ff064e691 in find_part /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60
#1 0x7f6ff0640788 in message_peek_body /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3283:16
#2 0x7f6ff064e8db in enter_struct_or_dict_entry /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3967:21
#3 0x7f6ff06444ac in bus_message_enter_struct /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4009:13
#4 0x7f6ff0641dde in sd_bus_message_enter_container /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4136:21
#5 0x7f6ff0619874 in sd_bus_message_dump /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-dump.c:178:29
#6 0x4293d9 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bus-message.c:39:9
#7 0x441986 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15
#8 0x44121e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
#9 0x443164 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7
#10 0x4434bc in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3
#11 0x42d2bc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6
#12 0x42978a in main /src/libfuzzer/FuzzerMain.cpp:19:10
#13 0x7f6fef13c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#14 0x407808 in _start (out/fuzz-bus-message+0x407808)
set_put()/set_ensure_put() return 0, not -EEXIST, if the entry is already
found in the set. In this case this does not make any difference, but let's
not confuse the reader.