In case kernel-install is called to install what's already a UKI, 60-ukify
must be skipped. E.g. when distro shipped and signed UKI is being installed,
it is counter-productive to try to rebuild it with ukify. Also, the existing
script is not ready to handle UKIs with embedded initramfs.
Note, it is already possible to disable 60-ukify by setting
KERNEL_INSTALL_UKI_GENERATOR to something but in case it is not set, 60-ukify
assumes it should run.
Identify an virtualbox instance even if product_name, sys_vendor and bios_vendor reflect the
information of the real hardware, by checking if board_vendor == "Oracle Corporation"
This fixes#13429 again
The previous fix was removed in #21127
Recreate the encryption session on each retry. It's invalidated along
with the policy session when freed, failing subsequent retries.
Unsealing HMAC key.
WARNING:esys:src/tss2-esys/api/Esys_Unseal.c:295:Esys_Unseal_Finish() Received TPM Error
ERROR:esys:src/tss2-esys/api/Esys_Unseal.c:98:Esys_Unseal() Esys Finish ErrorCode (0x00000128)
A PCR value changed during the TPM2 policy session, restarting HMAC key unsealing (30 tries left).
Missing encryption session
Failed to unseal secret using TPM2: Invalid argument
Fixes#31881
This patch fixes an issue where, when not specifiying either at least one
`SocketBindAllow` or `SocketBindDeny` rule, behavior for the bind syscall
filtering would be unexpected.
For example, when trying to bind to a port with only "SocketBindDeny=any"
given, the syscall would succeed:
> systemd-run -t -p "SocketBindDeny=any" nc -l 8080
Expected with this set of rules (also in accordance with the documentation)
would be an Operation not permitted error.
This behavior occurs because a default initialized socket_bind_rule struct
matches what "any" represents. When creating the bpf list all elements get
default initialized, as such represeting "any". Seemingly it is necressarry
to set the size of the map to at least one, as such if no allow rule is
given default initialization and minimal map size cause one any allow rule
to be in the map, causing the behavior observed above.
This patch solves this by introducing a new "match nothing" magic stored in
the rule's address family and setting such a rule as the first one if no
rule is given, making sure that default initialized rule structs are never
used.
Resolves#30556
I don't quite understand the rationale of making these
verbs work with --global back in the day. But realistically
they interact with/spawn manager, while there's no
--global runtime scope manager. And to verify/inspect user
units it's sufficient to just use --user.
Fixes#31911
Currently, SocketPeer object acquired through
socket_acquire_peer() are referenced twice
in socket_enter_running and service_set_socket_fd,
and the reference taken by former gets dropped
through _cleanup_. This is a bit confusing.
Let's just pass ownership instead.
This makes it possible to update a home record (and blob directory) of a
home area that's either completely absent (i.e. on a USB stick that's
unplugged) or just inaccessible due to lack of authentication
This bypasses authentication (i.e. user_record_authenticate) if the
volume key was loaded from the keyring and no secret section is
provided.
This also changes Update() and Resize() to always try and load the
volume key from the keyring. This makes the secret section optional for
these methods while still letting them function (as long as the home
area is active)
This commit makes homework always upload the LUKS volume key into the
kernel keyring. This is different from previous behavior in three
notable ways:
- Previously, we'd only upload if auto-resize was on. In preparation for
upcoming changes, now we always upload
- Previously, we'd upload the user's actual password (or a password
obtained from a FIDO key or similar). Now, we upload the LUKS volume key
itself, to remove a layer of unnecessary indirection.
- Previously, Lock() wouldn't remove the key from the kernel keyring.
This, of course, defeats the purpose of Lock(), so now it removes the
key
This commit also allows the LUKS volume to be unlocked using the volume
key we obtained from the keyring.
Before this fix, the following sequence of events was possible:
1. A client holding a Ref() FD closes their FD
2. kernel sends notification that all clients closed their FDs
3. Another client obtains its own Ref() FD from homed
4. homed handles the notification that all clients have closed their
Ref() FDs. Thus it loses track of the fact that the session is
actually still being held open by the client from step 3
This change makes sure that homed won't respond to bus messages (and
thus won't open more Ref() FDs) until it has handled all notifications
about the existing FDs being closed.
logind has had a very similar fix applied to it in
e11544a830
Fixes https://github.com/systemd/systemd/issues/31518
For CI in mkosi, I want to configure systemd to log at debug level
to the journal, but not to the console. While we already have max
level settings for journald's forwarding settings, not every log line
goes to the journal, specifically during early boot and when units
are connected directly to the console (think systemd-firstboot), so
let's extend the log level options we already have to allow specifying
a comma separated list of values and lets allow prefixing values with
the log target they apply to to make this possible.
Yu Watanabe
Vitaly Kuznetsov
Mike Yuan
Luca Boccassi
Friedrich Altheide
Gabríel Arthúr Pétursson
networkException
Zbigniew Jędrzejewski-Szmek
Adrian Vovk
Daan De Meyer
Frantisek Sumsal
Unique-Usman