It is useful to have stable and unique identifiers for a security
principal. The majority of identitiy management systems in use with Unix
systems today (e.g. Active Directory objectGUID, FreeIPA ipaUniqueID,
Kanidm UUIDs) assign each account and group a unique UUID and exposing
that to applications allows them to refer to accounts in a stable
manner.
At this time we are merely adding the properties to the user/group
records. Adding ways to perform lookups by these IDs is left for a
future PR.
See [discussion](https://mastodon.social/@pid_eins/114283987142625086) and
[this comment](https://github.com/systemd/systemd/issues/24032#issuecomment-2745246757).
I'm sure there are wording aspects which could be improved, but I
believe this is a reasonable initial stab at the problem.
It is useful to have stable and unique identifiers for a security principal.
The majority of identitiy management systems in use with Unix systems today
(e.g. Active Directory objectGUID, FreeIPA ipaUniqueID, Kanidm UUIDs) assign
each account and group a unique UUID and exposing that to applications allows
them to refer to accounts in a stable manner.
This change does not implement user or group lookup by UUID; that is left for
a later PR.
This replaces #36209 and implements this via a new builtin, rather than
by shelling out to systemd-dissect.
Replaces: #36209
Replaces: #28894Fixes: #34319Fixes: #33453Fixes: #27897Fixes: #18035
When dissecting an image, let's make use of the Verity data even if we
got told no root hash explicitly: we can simply determine it by
concatenating the data partition uuid with the verity partition uuid.
Of course, on first thought this doesn't really add much: if the root
hash is not pinned from somewhere, this does not guarantee trust in
the image.
However, this is very useful for attestation: if we have the root hash
we can measure it before mounting things, even if we don't actually
authenticate it.
Hence, at best this helps us with attestation, at worst it doesn't improve
security but certainly doesn't hurt it.
Now that mkosi can automatically pick up its main configuration from
a mkosi/ subdirectory if it exists and there is no configuration in the
top level directory, let's make use of it to reduce the amount of clutter
in the top level directory of the repository.
This will also make it easier to install the mkosi configuration files as
part of the testing packages later on.
Instead of listing dependencies manually for the default tools tree,
let's reuse the prepare scripts from the build image. To make this work,
the sync script has to be configured for the tools tree as well so that
it's invoked both when building the tools tree and for the regular image,
otherwise, when doing the first build in a fresh checkout, the sync script
won't have executed yet as sync scripts for the regular images are executed
after building the default tools tree.
Currently, to run the integration tests, it's still necessary to
install various other build tools besides meson: A compiler, gperf,
libcap, ... which we want to avoid in CI systems where we receive
prebuilt systemd packages and only want to test them. Examples are
Debian's autopkgtest CI and Fedora CI. Let's make it possible for
these systems to run the integration tests without having to install
any other build dependency besides meson by extracting the logic
required to run the integration tests with meson into a separate
subdirectory and adding a standalone top-level meson.build file which
can be used to configure a meson tree with as its only purpose running
the integration tests.
Practically, we do the following:
- all the integration test directories and integration-test-wrapper.py
are moved from test/ to test/integration-test/.
- All the installation logic is kept out of test/integration-test/ or
any of its subdirectories and moved into test/meson.build instead.
- We add test/integration-test/standalone/meson.build to run the
integration tests standalone. This meson file includes
test/integration-test via a cute symlink hack to trick meson into
including a parent directory with subdir().
- Documentation is included on how to use the new standalone mode.
- TEST-64-UDEV-STORAGE and TEST-85-NETWORK are changed to generate separate
units for each testcase to make them behave more like the other integration
tests.
This partially reverts 8d04b8198d.
If we completely drop the file, users will get a 404. But this document
has been in place for a long time and is referred to in many other places,
incl. our old wiki at https://www.freedesktop.org/wiki/Software/.
The page already says that it's been replaced
("… Please consult this document only as a historical reference. …").
We should only remove it from the index (which
8d04b8198d did).
In general, let's be more careful about preserving link stability.
When we change something in a way that breaks URLs, we're creating
pain for users.
Since this only covers user creation/registration for now, let's hide it
behind an env var. We might reconsider this eventually and make it a
proper switch one day, but who knows, it after all has this "debug tool"
wiff.
When we're building ParticleOS images, we don't want the package
manager (or mkosi) to run systemd-sysusers, systemd-tmpfiles or
systemctl preset so let's add a few more bypass environment
variables that we can set to have execution of these skipped like
we already have $SYSTEMD_HWDB_UPDATE_BYPASS and $KERNEL_INSTALL_BYPASS.
This has been depracted since v254 (2023). Let's kill it for
good now, it has been long enough with 2y. Noone has shown up who wants
to keep it. And given it doesn't work in SB world anyway, and is not
measured is quite problematic security wise.
mkosi now supports -R to rerun build scripts without rebuilding the
image so let's document that instead of the current hack to prevent
the rebuild by changing the output format.
mkosi now supports -R to rerun build scripts without rebuilding the
image so let's document that instead of the current hack to prevent
the rebuild by changing the output format.
In https://github.com/systemd/mkosi/pull/3497, mkosi has started parsing
options passed after the verb as regular mkosi options instead of options
for the invoked command. We adapt to this change by adding '--' as a delimiter
everywhere where required.
Update osCPE field example to use cpe 2.3 format, as is in active use by
AmazonLinux 2023 for example.
Add appCPE field example to document the upstream application CPE for the
applicable CVEs. Often distribution source package names are different from the
upstream CPE. For example adding/removing "lib" prefix, or adding version
stream "-3" suffix. This typically leads to guessing or fuzzy matching. Adding
appCPE in such cases can help to disambiguate (or collate) correct application
CPEs; especially beyond the lifetime of osCPE support timeframes.
This is preparation for adding server side filtering to the userdb
logic: it adds some fields for this to the userdb varlink API. This only
adds the IDL for it, no client will use it for now, no server implement
it. That's added in later commits.
HACKING.md should first and foremost tell someone how to hack on
systemd, installing packages from OBS isn't the most likely section
a new contributor will be interested in, so let's move it further
down.
With the latest mkosi, mkosi takes care of making sure it is
available within mkosi sandbox so we get rid of all the --preserve-env=
options when we invoke mkosi sandbox with sudo as these are not
required anymore. It also doesn't matter anymore if mkosi is installed
in /usr on the host so we get rid of the documentation around that as
well.
