Cockpit's podman plugin needs to know the lingering status so the UI can
advertise enabling `podman-restart` (which depends on lingering to
work). Currently it relies on watching `/var/lib/systemd/linger/${user}`
but that isn't a public API.
Related: #22244
First, let's say "must" rather than "shall" regarding creation of these
files, because without them group memberships will not work.
Secondly, suggest placing an empty JSON object in them, rather than
making them empty, simply to avoid issues with older systems that didn't
backport d6570eafe3.
Fixes: #38943
Followon to #37024.
This implements (mostly) what was suggested there, except that only a
single UUID is accepted (modifying things to support multiple is a
relatively straightforward change from here)
I'm not really convinced this is the right approach:
* I can't really think of any cases where you'd need to query by
multiple UUIDs (I guess you might want to lookup multiple users, but in
that case why aren't there "usernames" or "uids" arrays?)
* If I specify username "foo" and UID 1234 and UID 1234 exists and has
username "bar", I get back the error `ConflictingRecordFound`
* If I specify username "foo" and UUID abcdef... and username "foo"
exists but has UUID 123456..., I get back the error
`NonMatchingRecordFound`
This makes the two ID types behave differently.
Additionally, when querying by `uuid`, the multiplexer will always sends
`more: true`, which is fine but a little unexpected.
I do think unifying things through the `UserDBMatch` struct could make
sense, but in that case I think it would make sense to unify all query
types in that way (username, uid, uuid), identify when the filter is for
a single or multiple records, and centralise determination of conflict
vs non matching record errors.
`userdb_by_name`/`userdb_by_uid` could then become helper functions for
the simple case where no additional filtering is needed.
Thoughts?
One other thought: Should the multiplexer just pass through all
parameters, even unknown ones, to the backend services? Even if it
doesn't know how to filter by every property, the backends might, and it
would be useful to allow them to optimise things. (I realise the
disadvantage of this, ofc, is loss of error checking)
The ability to encrypt/authenticate encryption with a null key was
originally just a fallback concept for cases where during early boot we
have no host key, but the local system has no TPM2. Nowadays it is used
for other stuff as well, such as pcrlock data propagation (i.e. data
that needs no protection itself and required to properly to TPM key
derivation).
Let's give better, explicit control over null key usage, i.e. let's make
it a tristate both on the systemd-creds command line and in the Varlink
IPC to control three cases:
- the default that we allow it only if SecureBoot is off
- explicitly allowed
- explicitly refused (this is new)
Ideally systemd-creds --allow-null switch would take a boolean argument
to control this as a tristate. Alas, that would be a compat break, hence
I added --refuse-null instead (which also maps to the low-level flag for
this).
This also normalizes that the null key is always called "null key" in
messages, and not sometimes "empty key" or "fallback key".
The prohibition to move libsystemd objects between threads was added in
64a7ef8bc0 ('man: be more explicit about thread
safety of sd_journal'). At the time, this was valid, because we were using the
mempool for allocation and it apparently didn't handle access from different
threads. Sadlly, the commit links to a bugzilla entry referenced in the commit
is not publicly visible anymore, so the details are murky. But we stopped using
the mempool in a5d8835c78 ('mempool: only enable
mempool use when linked to libsystemd-shared.so'), with subsequent followup in
b01f31954f ('Turn mempool_enabled() into a weak
symbol'). The restriction added in the man page is not necessary since then.
The text in the man page was arguably incorrect in calling the code
"thread-agnostic". If the code does not support being touched from threads at
all and has global state to tied to the main thread, it is not "agnostic", but
just doesn't support threads.
(I'm looking into https://github.com/systemd/python-systemd/issues/143, and
with the current scheme, the python-systemd module and all python code using
libsystemd would be very hard to use. With the change to free-threaded python
in python3.13, i.e. the replacement of single Global Interpreter Lock by
locking on individual objects, this limitation would become even more
constraining.)
Most of those were dropped in 7d247d3cb8. I left
behind the few cases where the 'output' name was different from the target name.
But we actually don't need those either, so get rid of those. (And one case
where I missed the name argument.)
No functional change, except that e.g. 'ninja -C build update-man-rules-impl'
doesn't work, but I hope nobody was using that.
I exclude generated files from license check, and I noticed
that this file was marked with a license header, which doesn't
make much sense, it is not copyrightable.
Those were added before 0.61 which is our minimum version.
Dots were dropped from the end of some messages. Most messages did not have the
trailing dot.
0.63 added support for multi-line f-strings. We can't use those yet.
This adds what #39101 and #39070 did for the regular firstboot wizard
but for the homectl firstboot part: i.e. port to the generic prompt
loop, show the "chrome" bars, and mute the console.
And then it also makes querying for aux groups and shells optional,
because quite frankly, i am not sure what to answer there.
Add proper description section for udev_enumerate_new(), udev_enumerate_ref(),
and udev_enumerate_unref() functions. The description matches the source code
comments for consistency.
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
The keymap only really matters if there's local access to a system, i.e.
if there's actually a physical kbd directly connected to it, to apply it
to. If during firstboot we are not talked to via a VT (but via SSH,
container, or hypervisor console or so instead), then it's very unlikely
we ever are. Hence, don't ask for a keymap, and let#s shortcut the
questions asked at boot.
For "wizard" style interactive tools it's very annoying if they are
interrupted by kernel log output or PID1's status output. let's add some
infra to disable this temporarily. I decided to implement this as an IPC
service so that we can make this robust: if the client request the
muting dies we can automatically unmute again.
This is hence a tiny varlink service, but it can also be started
directly from the cmdline.
All other resource control features work as 'best-effort', and failures
in applying them are handled gracefully. However, unlike the other features,
we tested if the BPF programs can be loaded and refuse execution on failure.
Moreover, the previous behavior of testing loading BPF programs had
inconsistency: the test was silently skipped if the cgroup for the unit does
not exist yet, but tested when the cgroup already exists.
Let's not handle failures in loading custom BPF programs as critical, but
gracefully ignore them, like we do for the other resource control features.
Follow-up for fab347489f.
This is split out of #38764.
It mostly introduces the "chrome" stuff that puts a blue at the top of
bottom of the terminal screen when going through interactive tools such
as firstboot, homed-firstboot, and (in future) systemd-sysinstall).
it also introduces a generic "prompt_loop()" helper thatn queries the
user for some option in a loop until the rsponse matches certain
requirements. It's a generalization of a function of the same name that
so far only existed in firstboot.c. The more generic version will be
reused in a later PR by homed-firstboot and by sysinstall.
We'll soon have three different kind of interactive "wizard"-like console
UIs: systemd-firstboot, homectl firstboot and soon systemd-sysinstall.
Let's give them a limited, recognizable visual identity, to distinguish
them from the usual console output: let's add a bit of "chrome" to the
top and bottom of the screen, that we show during ther wizards, but hide
again afterwards.
This makes use of the DECSTBM sequence that reduces the scrolling area
by chopping off blocks from the top or bottom of the screen. The
sequence is quite standard, given it has been part of VT100 already.
xterm, vte, Linux console all support it just fine.
Current methods take a numeric PID, but we know that is unreliable for
the usual reasons. Add variants that take a PIDFD instead, or a
PID + PIDFDID combination for remote users.
Add support for generating names like wldN based on DeviceTree aliases.
DeviceTree alias names follow de facto conventions. As of writing, there
are so far two ways WLAN devices are represented in DeviceTree aliases
in upstream Linux DTS files:
- Firstly, as wifi0, used for example in t600x-j314-j316.dtsi
- Secondly, as ethernet0 or ethernet1, used for example in
sun8i-q8-common.dtsi, with a comment saying the reason is to "Make
u-boot set mac-address for wifi without an eeprom"
So we need to handle both while generating names. Refactor most of the
logic in names_devicetree() into a helper
names_devicetree_alias_prefix() that takes an alias_prefix instead of
hardcoding "ethernet", and, in the new names_devicetree():
- For prefix "en", use alias_prefix "ethernet"
- For prefix "wl", try alias_prefix "wifi" first, and if that was not
found, fall back to alias_prefix "ethernet"
Since this is a naming scheme change, also gate this behind
NAMING_DEVICETREE_ALIASES_WLAN and NAMING_V259, and document this
change.
Add support for generating names like wldN based on DeviceTree aliases.
DeviceTree alias names follow de facto conventions. As of writing, there
are so far two ways WLAN devices are represented in DeviceTree aliases
in upstream Linux DTS files:
- Firstly, as wifi0, used for example in t600x-j314-j316.dtsi
- Secondly, as ethernet0 or ethernet1, used for example in
sun8i-q8-common.dtsi, with a comment saying the reason is to "Make
u-boot set mac-address for wifi without an eeprom"
Therefore for prefix "wl", try alias_prefix "wifi" first, and if that
was not found, fall back to alias_prefix "ethernet"
Since this is a naming scheme change, also gate this behind
NAMING_DEVICETREE_ALIASES_WLAN and NAMING_V259, and document this
change.
Currently, a 15-second timeout is hardcoded for the key enrollment
process while waiting for user confirmation. Make this value configurable
to allow the option of disabling user input, such as during automatic key
provisioning at the factory.
Signed-off-by: Igor Opaniuk <igor.opaniuk@foundries.io>
In systemd <= 257, each set_audit tristate value had special meaning,
- true: enable the kernel audit subsystem,
- false: disable the kernel audit subsystem,
- negative: keep the current kernel audit subsystem state.
And the default is true, rather than negative. So, users sometimes
explicitly pass an empty string to Audit= setting to keep the state.
But since f48cf2a96d (v258), the negative
value is mistakenly used as 'really unspecified' even if an empty string
is explicitly specified.
This makes negative values handled as unspecified as usual, and assign a new
positive value AUDIT_KEEP for when an empty string is explicitly specified.
Also, make the Audit= setting accept "keep" setting, and suggest to use "keep"
rather than an empty string.
Fixes a regression caused by f48cf2a96d (v258).
Fixes#39057.
The options `--booted` is compared with the command `systemctl
is-system-running`, but the return values have differnt meanings and it
is not a drop-in.
let's skip over credentials we cannot decode when they are found with
ImportCredential=. When installing an OS on some disk and using that
disk on a different machine than assumed we'll otherwise end up with a
broken boot, because the credentials cannot be decoded when starting
systemd-firstboot. Let's handle this somewhat gracefully.
This leaves handling for LoadCredential=/SetCredential= as it is (i.e.
failure to decrypt results in service failure), because it is a lot more
explicit and focussed as opposed to ImportCredentials= which looks
everywhere, uses globs and so on and is hence very vague and unfocussed.
Fixes: #34740
Taylan Kammer
Jelle van der Waa
Lennart Poettering
Mike Yuan
Frantisek Sumsal
Antonio Alvarez Feijoo
Yu Watanabe
jsks
Zbigniew Jędrzejewski-Szmek
Managor
Osama Abdelkader
Michal SekletarandLennart Poettering
Pascal Bachor
Daan De Meyer
Luca Boccassi
dramforever
Igor Opaniuk
Christian Hesse