*ret_culprit should be set if ret_culprit has been passed a non-null value,
checking the previous *ret_culprit value does not make sense.
This would cause the culprit to not properly be assigned, leading to
pid1 crash when a unit could not be stopped.
Fixes: #21476
This adds uidmap shifting also when resizing/updating/changing
passwords. Prviously I thought we didn't have to, because the user is
not going to access the uidmap if we only quickly activate the home
area. But this thinking is wrong, because the three operations will
result in an update ~/.identity fie to be written, and we should do that
with uidmap applied, so that its ownership maps down to nobody below as
intended.
Fixes: #21441
When we want to operate on an already activated home area we so far
tried to reapply the uidmapping logic. We shouldn't do that, it's
already applied after all.
We only want to apply this for newly activated home areas. Hence check
for the right HomeSetupFlags flag for it HOME_SETUP_ALREADY_ACTIVATED.
The patch is actually in theory a two-liner. Except that so far we don#t
pass the HomeSetupFlags flags down all necessary functions where the
uidmap stuff will eventually run. Hence this larger than intended
commit.
In 57bb9bcba5 support was added to read
"cheap" passwords from env vars and stuff before issuing the first
operation, instead of waiting for it until the first operation failed.
This was added for most verbs of "homectl", but two were left out:
update + passwd. Add it there too.
We give a path, but the path is only meaningful inside of the image.
Some messages made it clear that it's a path in the image, let's make
them all do that.
The whole point of acquiring metadata is quite often to figure out why the
image does not pass verification. Refusing to provide metadata is just being
hostile to the user.
When called from other places (e.g. image_read_metadata()), verification is
still performed.
Linux 5.15 broke API in ioprio_get(): instead of returning
IOPRIO_CLASS_NONE when that's set it now returns IOPRIO_CLASS_BE, which
is what this actually is (the former is just an alias for the latter
with a priority value of 4).
Let's hide the differences between old and new kernels here, and always
normalize to what the new kernels do.
IOPRIO_CLASS_NONE with any priority value actually is an alias for
IOPRIO_CLASS_BE with priority value 4 – which is the default ioprio for
all processes.
We got this right at one place, but wrong at three others (where we
assumed the default value was 0, not 4). Let's add a
macro that encodes this properly, and use it everywhere.
To allow dissecting images of architectures other than the native
(or secondary) one, we add a third designator 'OTHER' to represent
architectures other than the native or secondary one.
If no partitions of the native or secondary arch are available, we
check if a root partition of any other arch is available and use that
instead if we found one.
One of the niceties of recurse_dir()/recurse_dir_at() is that the path
argument is decoration, it's not used for actually accessing the fs in
anyway. That's very handy in environments where chroots and relative
paths are used, as we can path in any path we like and the recursion
function will suffix with whatever it discovers but will not try to make
sense of the prefix you pass.
This works great, except that the recurse_dir_at() wrapper broke that:
it adjusted the path if NULL to "." simply for the sake of making
openat() on the top work. Let's make this adjustment more local and do
it only for the openat() itself, and otherwise pass the path through the
way we got it. This means: if a caller really wants the paths that are
concatenated to start with a "." it can just pass that. This way the
caller gets full control back of the path prefix. Win!
Note that all current users of recurse_dir_at() don't pass NULL as
second arg, hence this check is without any real effect for now. It's
preparation for future uses however.
With this the tool will show whether an image is intended to be a
bootable OS image, a system extension, or a portable service image.
Example output with this patch:
<snip>
Name: image_53.raw
Size: 3.2G
Machine ID: bb9f2921198040feb7c82270bf66e4b8
OS Release: NAME=Fedora
VERSION=34 (Thirty Four)
…
PRIVACY_POLICY_URL=https://fedoraproject.org/wiki/Legal:PrivacyPolicy
IMAGE_VERSION=53
Use As: ✓ bootable system for UEFI
✓ bootable system for container
✗ portable service
✗ extension for system
✗ extension for initrd
✗ extension for portable service
RW DESIGNATOR PARTITION UUID PARTITION LABEL FSTYPE ARCHITECTURE VERITY GROWFS NODE PARTNO
rw root d56af2b4-35eb-2e40-8f08-2d3b7012b0fc Root Partition btrfs x86-64 no no /dev/loop1p2 2
rw esp e3d11339-05c1-a74a-ae77-aae76812c134 ESP System Partition vfat - - no /dev/loop1p1 1
…
</snip>
This should make things a bit more robust since it ensures system
extension can only applied to the right environments. Right now three
different "scopes" are defined:
1. "system" (for regular OS systems, after the initrd transition)
2. "initrd" (for sysext images that apply to the initrd environment)
3. "portable" (for sysext images that apply to portable images)
If not specified we imply a default of "system portable", i.e. any image
where the field is not specified is implicitly OK for application to OS
images and for portable services – but not for initrds.
The argument names of methods under org.freedesktop.DBus.Properties and
org.freedesktop.DBus.Introspectable interfaces are specifies in D-Bus
specification[1]. They are:
org.freedesktop.DBus.Introspectable.Introspect (out STRING xml_data)
org.freedesktop.DBus.Properties.Get (in STRING interface_name,
in STRING property_name,
out VARIANT value);
org.freedesktop.DBus.Properties.Set (in STRING interface_name,
in STRING property_name,
in VARIANT value);
org.freedesktop.DBus.Properties.GetAll (in STRING interface_name,
out DICT<STRING,VARIANT> props);
sd-bus is using different argument names in the introspection document.
Usually this is not a problem but in case something tries to map the
argument names based on the introspection document to the position of
the arguments in the method call, then using names different than the
ones specified in the D-Bus specification is confusing.
So fix the names to match the D-Bus specification.
[1] https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable
There is no functional change, but this reduces the risk that
in some future refactoring we'll forget the do the initialization in all
execution paths.
Use product_version instead of product_name in DMI table and the string
"Hyper-V" to avoid misdetection.
Fixes: #21468
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Daan De Meyer
Lennart Poettering
Dominique Martinet
Zbigniew Jędrzejewski-Szmek
Julia Kartseva
Miika Karanki
Boqun Feng