similar as the previous commit, let's clean up the credential name we
use. Use home.token-pin in case of homectl, and cryptenroll.pkcs11-pin
in case of cryptenroll.
Querying a fido2 PIN via askpw for enrolling is currently used in two
places: cryptenroll and homectl. So far we sloppily used the same fixed
credential name "fido2-pin" in both cases. Let's tweak that and make the
credential name match the other credentials cryptenroll or home query,
i.e. using the cryptenroll.* and home.* namespaces.
This is particular done in light of #31370, which wants to make the
credential name public. We really should get the name in order before
making it public.
Rather than adding more and more parameters to ask_password_auto(), let's
pass a structure of the fields that often are constant anyway.
This way, callers can fill in what they need, and we take the filled
structure which we can pass around internally as one.
This is in particular preparation for adding one more field in one of
the next commits.
Follow-ups for e1634bb832.
- Allow to call the method without "name" and "type".
- Allow to specify SD_RESOLVE_NO_TXT and SD_RESOLVE_NO_ADDRESS.
- Allow to provide multiple services, and fix memory leak.
- Rearrange the return value format.
- Encode TXT field with octescape() to make the field matches with the
io.systemd.Resolve.Monitor interface.
Fixes#31371.
Avoid the following warning on C9S by explicitly initializing
"object".
"""
[389/2801] Compiling C object src/shared/libsystemd-shared-256-devel.a.p/pkcs11-util.c.o
../src/src/shared/pkcs11-util.c: In function ‘pkcs11_token_find_private_key’:
../src/src/shared/pkcs11-util.c:983:21: warning: ‘object’ may be used uninitialized in this function [-Wmaybe-uninitialized]
983 | *ret_object = object;
| ~~~~~~~~~~~~^~~~~~~~
"""
This is useful for situations where an array of FDs is to be passed into
a child process (i.e. by passing it through safe_fork). This function
can be called in the child (before calling exec) to pack the FDs to all
be next to each-other starting from SD_LISTEN_FDS_START (i.e. 3)
The varlink_collect_full function did not set varlink client's state
when the reply was an error. The state was stuck in "collecting-reply".
I discovered that while hacking on network varlink interface (adding a
new varlink method). The debug logs shows the process of performing the
first query which replies with an error:
varlink: Setting state idle-client
network: Sending message: {"method":"io.systemd.Network.LLDPNeighbors","parameters":{"ifindex":1},"more":true}
network: Changing state idle-client → collecting
network: Received message: {"error":"org.varlink.service.MethodNotFound","parameters":{"method":"io.systemd.Network.LLDPNeighbors"}}
network: Changing state collecting → collecting-reply
Now another varlink_collect call is being made, but
network: Connection busy.
Failed to execute varlink call: Device or resource busy
This was not caught by the tests because there were no varlink_collect
calls that resulted in error reply.
According to keyctl(2), the return value for KEYCTL_READ is:
The amount of data that is available in the key,
irrespective of the provided buffer size
So, we could pass in a NULL buffer to query the size, then allocate the
exact right amount of space, then call keyctl again to get the key data.
However, we must still keep the for loop to avoid TOCTOU issues: the key
might have been replaced with something bigger while we're busy
allocating the buffer to store it.
Thus, we can actually save a syscall by picking some reasonable default
buffer size and skipping the NULL call to keyctl. If our default is big
enough, we're done and have saved a syscall! If not, then the first call
behaves essentially the same as the NULL call, and we use the size it
returns to reallocate the buffer appropriately.
owneridmap bind option will map the target directory owner from inside the
container to the owner of the directory bound from the host filesystem.
This will ensure files and directories created in the container will be owned
by the directory owner of the host filesystem. All other users will remain
unmapped. Files to be written as other users in the container will not be
allowed.
Resolves: #27037
I understand that the original motivation to introduce the template
argument here is to make journal_file_open() and _reliabrly() take the
same arguments. But, yeah, that's completely unused, not necessary to
complicate the code even the difference is not big.
Let's make sure that versions generated by meson-vcs-tag.sh always
sort higher than official and stable releases. We achieve this by
immediately updating the meson version in meson.build after a new
release. To make sure this version always sorts lower than future
rcs, we suffix it with "~devel" which will sort lower than "~rcX".
The new release workflow is to update the version in meson.build
for each rc and the official release and to also update the version
number after a new release to the next development version.
The full version is exposed as PROJECT_VERSION_FULL and used where
it makes sense over PROJECT_VERSION.
We also switch to reading the version from a meson.version file in
the repo instead of hardcoding it in meson.build. This makes it
easier to access both inside and outside of the project.
The meson-vcs-tag.sh script is rewritten to query the version from
meson.version instead of passing it in via the command line. This
makes it easier to use outside of systemd since users don't have to
query the version themselves first.
Our function so far assumed that the LoaderEntries's last string is or
is not NUL terminated. But if it was, then we'd debug log about this,
claiming there was an invalid id. sd-boot actually ends the list in a
properly NUL-terminated string, hence we should just accept that. Handle
that case gracefully, and add comments explaining why we have two ways
why we exit the loop.
This is cosmetic only, just suppresses a misleading debug log message.
This adds fields to the user record logic to allow a "fallback" home
directory and shell to be set as part of the "status" section of the
user record, i.e. supplied by the manager of the user record.
The idea is that if the fallback homedir/shell is set it will take
precedence over the real one in most ways.
Usecase: let's try to make ssh logins into homed directories work.
systemd-homed would set a fallback shell/homedir for inactive home dirs.
Thus, when ssh logins take place via key auth, we can allow them, and
these fallback session params would be used because the real home cannot
be activated just yet becasue we cannot acquire any password for it from
the user.
An UKI final command line is not just made of the content of .cmdline,
but also from the addons that are inserted in
/boot/efi/EFI/Linux/<UKI_NAME>.efi.extra.d (local addons) and /boot/efi/loader/addons
(global addons).
Therefore bootclt "status" and "list" should also include these addons
when printing the UKI command line.
Support for /boot/efi/EFI/Linux/<UKI_NAME>.efi.extra.d is already present,
so now cover addons present in /boot/efi/loader/addons (global addons).
Example (assume UKI_NAME=devel):
$ bootctl
ukiCmdline: console=tty0 console=ttyS0
globalAddon: loader/addons/global.addon.efi
cmdline: └─quiet
localAddon: devel.efi.extra.d/rpm_addon.addon.efi
cmdline: └─this is a normal addon
finalCmdline: console=tty0 console=ttyS0 quiet this is a normal addon
An UKI final command line is not just made of the content of .cmdline,
but also from the addons that are inserted in
/boot/efi/EFI/Linux/<UKI_NAME>.efi.extra.d (local addons) and
/boot/efi/loader/addons (global addons).
Therefore bootclt "status" and "list" should also include these addons
when printing the UKI command line.
Right now, discover addons present in
/boot/efi/EFI/Linux/<UKI_NAME>.efi.extra.d.
Example output (assume UKI_NAME=devel):
$ bootctl
ukiCmdline: console=tty0 console=ttyS0
localAddon: devel.efi.extra.d/rpm_addon.addon.efi
cmdline: └─this is a normal addon
finalCmdline: console=tty0 console=ttyS0 this is a normal addon
This field is like preferredLanguage, but takes a priority list of
languages instead. If an app isn't translated into a user's primary
language, it can fall back to one of the other languages in the list
thus making the app more accessible to the user.
For instance: in my experience, many Ukrainians are fluent in Russian,
often significantly better than English (especially if they are of a
generation that grew up during the USSR). Such a person might set this
new variable to ["uk_UA.UTF-8", "ru_UA.UTF-8"] so that software that
lacks Ukrainian translations will first try Russian translations before
defaulting to English.
Fixes#31290
ADD_SAFE/SUB_SAFE/MUL_SAFE do addition/subtraction/multiplication
respectively with an overflow check. If an overflow occurs these return
false, otherwise true. Example: (c = a + b) would become ADD_SAFE(&c, a,
b)
INC_SAFE/DEC_SAFE/MUL_ASSIGN_SAFE are like above but they also reassign
the first argument. Example: (a += b) would become INC_SAFE(&a, b)
Kinda sad, that interfaces like this exist in 2024. But let's deal with
it: before we access "struct btrfs_ioctl_search_header" let's copy it
out, and access it only in the aligned copy.
Fixes: #31282
The structure we copy this out is a large (unaligned) binary blob, hence
let's better use the memdup_suffix0() so that gcc doesn't make
assumption about the source being a valid string.