summaryrefslogtreecommitdiffstats
path: root/src/shared (follow)
Commit message (Collapse)AuthorAgeFilesLines
* shared/bootspec: mark _to_string funcs as _const_Mike Yuan2 days1-5/+4
| | | | Addresses https://github.com/systemd/systemd/pull/34959#discussion_r1860451777
* shared/bootspec: use FOREACH_ELEMENT where appropriate, avoid unneeded memzero()Mike Yuan2 days1-8/+8
|
* shared/bootspec: move boot_entry_addons_done() up, drop separate prototypeMike Yuan2 days1-12/+10
| | | | Follow-up for e2501a851e10f5279862b2bccbdd9184572cce6a
* bootspec: Look at /loader/addons in XBOOTLDRAdrian Vovk2 days2-28/+76
| | | | | | | | | | | | | | The bootspec util-lib's handling of global addons didn't previously match the behavior of sd-stub, and this commit corrects that. First, bootspec didn't load global addons from the XBOOTLDR dir, but the stub does. So, bootspec now enumerates addons in XBOOTLDR, not just ESP Second, the stub only loads resources (including addons) from the partition that it was found on. Thus, we must keep track of which partition the global addons come from, and which partition each boot entry comes from. In other words: global addons found on the ESP will NOT apply to UKIs found in XBOOTLDR, and bootspec now reflects that.
* bootspec: Fixup loading of local addons for UKIsAdrian Vovk3 days1-5/+7
| | | | Follow-up for 59b3df9
* bootspec: Fixup memory leakAdrian Vovk3 days2-4/+5
| | | | | This would previously leak memory: the array was deleted but contents inside of the array were not
* cryptsetup: convert pkcs11/fido2 to iovec for key handlingLuca Boccassi3 days2-10/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | key-data might be NULL. Fixes crash: 0 0x0000559c62120530 in attach_luks_or_plain_or_bitlk (cd=0x559c6b192830, name=0x7ffd57981dc4 "root", token_type=TOKEN_FIDO2, key_file=0x0, key_data=0x0, passwords=0x0, flags=524296, until=0) at ../src/cryptsetup/cryptsetup.c:2234 pass_volume_key = false r = 1469577760 __func__ = '\000' <repeats 29 times> 1 0x0000559c6212279c in run (argc=6, argv=0x7ffd5797fe98) at ../src/cryptsetup/cryptsetup.c:2597 discovered_key_data = {iov_base = 0x0, iov_len = 0} key_data = 0x0 token_type = TOKEN_FIDO2 destroy_key_file = 0x0 flags = 524296 until = 0 passphrase_type = PASSPHRASE_NONE volume = 0x7ffd57981dc4 "root" source = 0x7ffd57981dc9 "/dev/disk/by-uuid/8372fb39-9ba4-461a-a618-07dcaae66280" status = CRYPT_INACTIVE tries = 0 key_file = 0x0 config = 0x7ffd57981e05 "luks,discard,fido2-device=auto,x-initrd.attach" use_cached_passphrase = true try_discover_key = true discovered_key_fn = 0x7ffd5797fa70 "root.key" passwords = 0x0 cd = 0x559c6b192830 verb = 0x7ffd57981dbd "attach" r = 0 __func__ = "\000\000\000" 2 0x0000559c621231e6 in main (argc=6, argv=0x7ffd5797fe98) at ../src/cryptsetup/cryptsetup.c:2674 r = 32553 __func__ = "\000\000\000\000" Follow-up for 53b6c99018f918a5d2c9000ac5fe3a2440115ea7
* tpm2-util: fix parameter nameAntonio Alvarez Feijoo7 days1-1/+1
|
* killall: gracefully handle processes inserted into containers via nsenter -aLennart Poettering9 days1-2/+6
| | | | | | | | | "nsenter -a" doesn't migrate the specified process into the target cgroup (it really should). Thus the cgroup will remain in a cgroup that is (due to cgroup ns) outside our visibility. The kernel will report the cgroup path of such cgroups as starting with "/../". Detect that and print a reasonably error message instead of trying to resolve that.
* user-record: distinguish explicit and implicit empty modifiable lists caseLennart Poettering10 days1-6/+13
| | | | | | | | We now distinguish two cases: where the list of self modifiable fields is explicitly set to empty, and where the default is empty. Let's display them differently in the output. When set explicitly to empty let's mention the admin, otherwise just say "none".
* user-record: only synthesize default list of self-modifiable fields for ↵Lennart Poettering10 days1-3/+16
| | | | | | | | | | | | *regular* users For system users we should lock things down, hence generate an empty list. This is mostly a safety precaution, but also hides really confusing output of "userdbctl user" for an system user. Follow-up for: a192250eda1e5cc1f8fc799cf9b85d37e7fa0519
* async: block SIGTERM in asynchronous_rm_rf()Mike Yuan2024-11-141-0/+4
| | | | See justifications at https://github.com/systemd/systemd/pull/32235#issuecomment-2062327783
* ptyfwd: ellipsize overly long window titlesLennart Poettering2024-11-131-4/+20
| | | | | | | | | | Apparently some terminal emulators have problems with overly long titles, hence truncate them at some safe length (128). Also, when parsing ANSI sequences ourselves accept longer sequences (192), after all we should be fine when parsing our own title sequences. Fixes: #35104
* dissect-image: remove dead codeLennart Poettering2024-11-121-4/+0
|
* Various multi-dt fixes and CHID test (#35056)Yu Watanabe2024-11-101-0/+19
|\ | | | | Part of #34158
| * test: Add chid-fundamental testanonymix0072024-11-071-0/+19
| |
* | udev: skipping empty udev rules file while collecting the statsLidong Zhong2024-11-091-0/+4
| | | | | | | | | | | | | | | | To keep align with the logic used in udev_rules_parse_file(), we also should skip the empty udev rules file while collecting the stats during manager reload. Otherwise all udev rules files will be parsed again whenever reloading udev manager with an empty udev rules file. It's time consuming and the following uevents will fail with timeout.
* | mount-util: make path_get_mount_info() work arbitrary inodeYu Watanabe2024-11-082-38/+59
| | | | | | | | | | | | Follow-up for d49d95df0a260aaca9a3fdd1e6ce535592a53bca. Replaces 9a032ec55a9820a0424309670fe551c99203e5f1. Fixes #35075.
* | tree-wide: Introduce --certificate-source= optionDaan De Meyer2024-11-072-26/+139
| | | | | | | | | | | | | | This allows loading the X.509 certificate from an OpenSSL provider instead of a file system path. This allows loading certficates directly from hardware tokens instead of having to export them to a file on disk first.
* | openssl-util: Set expected object type to private keysDaan De Meyer2024-11-071-0/+3
|/ | | | | Configures the store to only try to fetch private keys and nothing else.
* Introduce systemd-sbsign to do secure boot signing (#35021)Daan De Meyer2024-11-064-111/+414
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in mkosi and ukify we use sbsigntools to do secure boot signing. This has multiple issues: - sbsigntools is practically unmaintained, sbvarsign is completely broken with the latest gnu-efi when built without -fshort-wchar and upstream has completely ignored my bug report about this. - sbsigntools only supports openssl engines and not the new providers API. - sbsigntools doesn't allow us to cache hardware token pins in the kernel keyring like we do nowadays when we sign stuff ourselves in systemd-repart or systemd-measure There are alternative tools like sbctl and pesign but these do not support caching hardware token pins in the kernel keyring either. To get around the issues with sbsigntools, let's introduce our own tool systemd-sbsign to do secure boot signing. This allows us to take advantage of our own openssl infra so that hardware token pins are cached in the kernel keyring as expected and we get openssl provider support as well.
| * Introduce systemd-sbsign to do secure boot signingDaan De Meyer2024-11-063-4/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in mkosi and ukify we use sbsigntools to do secure boot signing. This has multiple issues: - sbsigntools is practically unmaintained, sbvarsign is completely broken with the latest gnu-efi when built without -fshort-wchar and upstream has completely ignored my bug report about this. - sbsigntools only supports openssl engines and not the new providers API. - sbsigntools doesn't allow us to cache hardware token pins in the kernel keyring like we do nowadays when we sign stuff ourselves in systemd-repart or systemd-measure There are alternative tools like sbctl and pesign but these do not support caching hardware token pins in the kernel keyring either. To get around the issues with sbsigntools, let's introduce our own tool systemd-sbsign to do secure boot signing. This allows us to take advantage of our own openssl infra so that hardware token pins are cached in the kernel keyring as expected and we get openssl provider support as well.
| * openssl-util: Set default UI method instead of setting engine methodDaan De Meyer2024-11-052-114/+77
| | | | | | | | | | | | | | | | | | While for engines we have ENGINE_ctrl() to set the UI method for the second PIN prompt, for openssl providers we don't have such a feature which means we get the default openssl UI for the second pin prompt. Instead, let's set the default UI method which does get used for the second pin prompt by the pkcs11 provider.
| * pcrlock: Move pe_hash() and uki_hash() to pe-binary.hDaan De Meyer2024-11-053-1/+275
| | | | | | | | | | Let's move these to shared so we can reuse pe_hash() in the upcoming systemd-sbsign.
* | introduce report_errno_and_exit() helper (#35028)Luca Boccassi2024-11-063-39/+14
|\ \ | | | | | | | | | | | | This is a follow for https://github.com/systemd/systemd/pull/34853. In particular, this comment https://github.com/systemd/systemd/pull/34853#discussion_r1825837705.
| * | use report_errno_and_exit() in src/shared/elf-util.cIvan Kruglov2024-11-061-11/+5
| | |
| * | use report_errno_and_exit() in src/shared/dissect-image.cIvan Kruglov2024-11-061-9/+4
| | |
| * | use report_errno_and_exit() in src/shared/mount-util.cIvan Kruglov2024-11-061-19/+5
| | |
* | | machine: introduce io.systemd.Machine.Open method (#34867)Luca Boccassi2024-11-062-37/+40
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This PR introduces io.systemd.Machine.Open method which combines three DBus alternatives: - OpenMachinePTY - OpenMachineLogin - OpenMachineShell The PR contains basic tests.
| * | | machine: introduce io.systemd.Machine.Open methodIvan Kruglov2024-11-061-1/+38
| | | |
| * | | json: introduce json_dispatch_strv_environment()Ivan Kruglov2024-11-061-36/+2
| |/ / | | | | | | | | | | | | I just moved json_dispatch_environment() from src/shared/user-record.c under name 'json_dispatch_strv_environment()' to shared json code.
* / / pid1: stop refusing to boot with cgroup v1Zbigniew Jędrzejewski-Szmek2024-11-063-23/+49
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since v256 we completely fail to boot if v1 is configured. Fedora 41 was just released with v256.7 and this is probably the first major exposure of users to this code. It turns out not work very well. Fedora switched to v2 as default in F31 (2019) and at that time some people added configuration to use v1 either because of Docker or for other reasons. But it's been long enough ago that people don't remember this and are now very unhappy when the system refuses to boot after an upgrade. Refusing to boot is also unnecessarilly punishing to users. For machines that are used remotely, this could mean somebody needs to physically access the machine. For other users, the machine might be the only way to access the net and help, and people might not know how to set kernel parameters without some docs. And because this is in systemd, after an upgrade all boot choices are affected, and it's not possible to e.g. select an older kernel for boot. And crashing the machine doesn't really serve our goal either: we were giving a hint how to continue using v1 and nothing else. If the new override is configured, warn and immediately boot to v1. If v1 is configured w/o the override, warn and wait 30 s and boot to v2. Also give a hint how to switch to v2. https://bugzilla.redhat.com/show_bug.cgi?id=2323323 https://bugzilla.redhat.com/show_bug.cgi?id=2323345 https://bugzilla.redhat.com/show_bug.cgi?id=2322467 https://www.reddit.com/r/Fedora/comments/1gfcyw9/refusing_to_run_under_cgroup_01_sy_specified_on/ The advice is to set systemd.unified_cgroup_hierarchy=1 (instead of removing systemd.unified_cgroup_hierarchy=0). I think this is easier to convey. Users who are understand what is going on can just remove the option instead. The caching is dropped in cg_is_legacy_wanted(). It turns out that the order in which those functions are called during early setup is very fragile. If cg_is_legacy_wanted() is called before we have set up the v2 hierarchy, we incorrectly cache a true answer. The function is called just a handful of times at most, so we don't really need to cache the response.
* | mount-util: introduce path_is_network_fs_harder()Yu Watanabe2024-11-052-0/+70
| | | | | | | | It also detects e.g. glusterfs or mounts with "_netdev" option.
* | Add PrivatePIDs= (continued) (#34940)Luca Boccassi2024-11-051-1/+2
|\ \ | |/ |/|
| * core: Introduce PrivatePIDs=Daan De Meyer2024-11-051-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This new setting allows unsharing the pid namespace in a unit. Because you have to fork to get a process into a pid namespace, we fork in systemd-executor to get into the new pid namespace. The parent then sends the pid of the child process back to the manager and exits while the child process continues on with the rest of exec_invoke() and then executes the actual payload. Communicating the child pid is done via a new pidref socket pair that is set up on manager startup. We unshare the PID namespace right before the mount namespace so we mount procfs correctly. Note PrivatePIDs=yes always implies MountAPIVFS=yes to mount procfs. When running unprivileged in a user session, user namespace is set up first to allow for PID namespace to be unshared. However, when running in privileged mode, we unshare the user namespace last to ensure the user namespace does not own the PID namespace and cannot break out of the sandbox. Note we disallow Type=forking services from using PrivatePIDs=yes since the init proess inside the PID namespace must not exit for other processes in the namespace to exist. Note Daan De Meyer did the original work for this commit with Ryan Wilson addressing follow-ups. Co-authored-by: Daan De Meyer <daan.j.demeyer@gmail.com>
* | daemon-util: expose notify_push_fd()Yu Watanabe2024-11-042-1/+2
|/ | | | It will be used in a later commit.
* efi-loader: add missing stub for efi_stub_get_device_part_uuid()Franck Bui2024-11-041-0/+4
|
* openssl-util: Query engine/provider pin via ask-passwordDaan De Meyer2024-11-032-15/+248
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In mkosi, we want to support signing via a hardware token. We already support this in systemd-repart and systemd-measure. However, if the hardware token is protected by a pin, the pin is asked as many as 20 times when building an image as the pin is not cached and thus requested again for every operation. Let's introduce a custom openssl ui when we use engines and providers and plug systemd-ask-password into the process. With systemd-ask-password, the pin can be cached in the kernel keyring, allowing us to reuse it without querying the user again every time to enter the pin. We use the private key URI as the keyring identifier so that the cached pin can be shared across multiple tools. Note that if the private key is pin protected, openssl will prompt both when loading the private key using the pkcs11 engine and when actually signing the roothash. To make sure our custom UI is used when signing the roothash, we have to also configure it with ENGINE_ctrl() which takes a non-owning pointer to the UI_METHOD object and its userdata object which we have to keep alive so we introduce a new AskPasswordUserInterface struct which we use to keep both objects alive together with the EVP_PKEY object. Because the AskPasswordRequest struct stores non-owning pointers to its fields, we change repart to store the private key URI as a global variable again instead of the EVP_PKEY object so that we can use the private key argument as the keyring field of the AskPasswordRequest instance without running into lifetime issues.
* efivars: Remove STRINGIFY() helper macrosDaan De Meyer2024-11-024-25/+25
| | | | | | | | The names of these conflict with macros from efi.h that we'll move to efi-fundamental.h in a later commit. Let's avoid the conflict by getting rid of these helpers. Arguably this also improves readability by clearly indicating we're passing arbitrary strings and not constants to the macros when we invoke them.
* ask-password: Add $SYSTEMD_ASK_PASSWORD_KEYRING_TYPEDaan De Meyer2024-11-021-1/+45
| | | | | | | | | Currently ask_password_auto() will always try to store the password into the user keyring. Let's make this configurable so that we can configure ask_password_auto() into the session keyring. This is required when working with user namespaces, as the user keyring is namespaced by user namespaces which makes it impossible to share cached keys across user namespaces by using the user namespace while this is possible with the session keyring.
* ask-password: Drop "default" for SYSTEMD_ASK_PASSWORD_KEYRING_TIMEOUT_SECDaan De Meyer2024-11-021-1/+1
| | | | Users can simply unset the environment variable to achieve the same effect.
* ask-password: Use default timeout if ↵Daan De Meyer2024-11-021-4/+2
| | | | | | SYSTEMD_ASK_PASSWORD_KEYRING_TIMEOUT_SEC is unset Follow-up for d9f4dad986dcebd51bdaeb8ba3d2c00cdc0d701e
* pam: quiet a spurious debug messageRonan Pigott2024-11-022-2/+3
| | | | | This singular debug message gets printed even if debug is not enabled. Quiet this message when debug is not enabled for consistency.
* user-record: add missing comma to list of stringsLuca Boccassi2024-11-021-1/+1
| | | | Follow-up for ad03f2d5f0d7f87b775357e5a2727dbcbc973fce
* machine: introduce io.systemd.MachineImage.{Clone, Remove} methods (#34853)Luca Boccassi2024-11-021-5/+27
|\ | | | | | | This PR introduces io.systemd.MachineImage.Clone and Remove methods. They are 1:1 mapping to DBus alternatives.
| * machine: reuse VARLINK_DEFINE_IMAGE_LOOKUP_AND_POLKIT_FIELDS in ↵Ivan Kruglov2024-11-011-4/+2
| | | | | | | | io.systemd.MachineImage.Update declaration
| * machine: introduce io.systemd.MachineImage.Remove methodIvan Kruglov2024-11-011-0/+6
| |
| * machine: introduce io.systemd.MachineImage.Clone methodIvan Kruglov2024-11-011-1/+19
| |
* | core: add id-mapped mount support for Exec directoriesAndres Beltran2024-11-013-5/+6
|/
* tweaks to ANSI sequence (OSC) handling (#34964)Luca Boccassi2024-11-012-10/+17
|\ | | | | | | | | | | Fixes: #34604 Prompted by that I realized we do not correctly recognize both "ST" sequences we want to recognize, fix that.
generated by cgit v1.2.3 (git 2.39.1) at 2024-11-29 15:43:48 +0100