Type `simple` explicitly mentions that invocation failures like a missing binary
or `User=` name won’t get detected – whereas type `exec` mentions that it does.
Type `oneshot` refers to being similar to `simple`, which could lead one to
assume it doesn’t detect such invocation failures either – it seems however it
does.
Indicate this my changing its wording to be similar to `exec`.
Signed-off-by: Christoph Anton Mitterer <mail@christoph.anton.mitterer.name>
So far repart always required specification of a device node. And if
none was specified, then we'd fine the node backing the root fs. Let's
optionally allow that the device node is explicitly not specified (i.e.
specified as "-" or ""), in which case we'll just print the size of the
minimal image given the definitions.
RootDirectory= but via a open_tree() file descriptor. This allows
setting up the execution environment for a service by the client in a
mount namespace and then starting a transient unit in that execution
environment using the new property.
We also add --root-directory= and --same-root-dir= to systemd-run to
have it run services within the given root directory. As systemd-run
might be invoked from a different mount namespace than what systemd is
running in, systemd-run opens the given path with open_tree() and then
sends it to systemd using the new RootDirectoryFileDescriptor= property.
RootDirectory= but via a open_tree() file descriptor. This allows
setting up the execution environment for a service by the client in
a mount namespace and then starting a transient unit in that execution
environment using the new property.
We also add --root-directory= and --same-root-dir= to systemd-run to
have it run services within the given root directory. As systemd-run
might be invoked from a different mount namespace than what systemd is
running in, systemd-run opens the given path with open_tree() and then
sends it to systemd using the new RootDirectoryFileDescriptor= property.
--empower gives full privileges to a non-root user. Currently this
includes all capabilities but we leave the option open to add more
privileges via this option in the future.
Why is this useful? When running privileged development or debugging
commands from your home directory (think bpftrace, strace and such),
you want any files written by these tools to be owned by your current
user, and not by the root user. run0 --empower will allow you to run
all privileged operations (assuming the tools check for capabilities
and not UIDs), while any files written by the tools will still be owned
by the current user.
This creates a chicken-and-egg problem: we stuff the pcrlock policy into
a credential in the ESP, but credentials get measured into PCR 12, hence
PCR 12 is both input and output of the pcrlock logic, which makes
impossible to calculate.
Let's drop PCR 12 for now.
(We might want to pass the policy some other way one day, to avoid this,
but that's something for another day.)
Note that this still allows locking to PCR12 if people want to (for
example because they don't need this for the rootfs, and hence need no
cred passing via the ESP), this hence only changes the default, nothing
more.
Fixes: #33546
So even if a <term> section contains newlines, we get a reasonable
anchor link to it.
Before:
```
<dt id="
bind
UNIT
PATH
[PATH]
"><span class="term">
...
<a class="headerlink" title="Permalink to this term" href="#%0A%20%20%20%20%20%20%20%20%20%20%20%20bind%0A%20%20%20%20%20%20%20%20%20%20%20%20UNIT%0A%20%20%20%20%20%20%20%20%20%20%20%20PATH%0A%20%20%20%20%20%20%20%20%20%20%20%20[PATH]%0A%20%20%20%20%20%20%20%20%20%20">¶</a>
```
After:
```
<dt id="bind UNIT PATH [PATH]"><span class="term">
...
<a class="headerlink" title="Permalink to this term" href="#bind%20UNIT%20PATH%20[PATH]">¶</a>
```
Resolves: https://github.com/systemd/systemd/issues/39196
---
The reverts are not strictly necessary here (as already pointed out in
https://github.com/systemd/systemd/pull/39154#issuecomment-3360118164)
but they were helpful in checking if the fix works as expected. I can
drop them if needed.
So even if a <term> section contains newlines, we get a reasonable
anchor link to it.
Before:
<dt id="
bind
UNIT
PATH
[PATH]
"><span class="term">
...
<a class="headerlink" title="Permalink to this term" href="#%0A%20%20%20%20%20%20%20%20%20%20%20%20bind%0A%20%20%20%20%20%20%20%20%20%20%20%20UNIT%0A%20%20%20%20%20%20%20%20%20%20%20%20PATH%0A%20%20%20%20%20%20%20%20%20%20%20%20[PATH]%0A%20%20%20%20%20%20%20%20%20%20">¶</a>
After:
<dt id="bind UNIT PATH [PATH]"><span class="term">
...
<a class="headerlink" title="Permalink to this term" href="#bind%20UNIT%20PATH%20[PATH]">¶</a>
Resolves: #39196
As discussed in this thread:
https://github.com/redhat-performance/tuned/issues/798#issuecomment-3197697654
/usr/share/factory/ is not intended to be read from by programs,
but the wording in the FHS can be misread to think that programs
should be using /usr/share/factory/ as the vendor supplied configuration
directory rather than something like /usr/lib/foo/ or /usr/share/foo/.
This commit points developers to the UAPI configuration spec for how to
make their programs hermetic /usr/ compatible.
Signed-off-by: Ryan Brue <ryanbrue.dev@gmail.com>
Although extremely unlikely, there is a race present in solely checking the
$LISTEN_PID environment variable, due to PID recycling. Fix that by introducing
$LISTEN_PIDFDID, which contains the 64-bit ID of a pidfd for the child process
that is not subject to recycling.
Needed to implement support for RootHashSignature=/RootVerity=/RootHash=
and friends when going through mountfsd, for example with user units,
so that system and user units provide the same features at the same
level
Needed to implement support for RootHashSignature=/RootVerity=/RootHash=
and friends when going through mountfsd, for example with user units,
so that system and user units provide the same features at the same
level
When varlink parameters are empty, omit the "parameters" field entirely
rather than sending "parameters":{}. This reduces message size and
follows varlink specification which allows parameters to be omitted.
The implementation supports three equivalent representations for empty
parameters: field omission, JSON null, and empty object {}. All three
are accepted on input for backward compatibility.
Fixes: #38474
RootDirectory= and other options already implicitly enable PrivateUsers=
since 6ef721cbc7 if they are set in user
units, so that they can work out of the box.
Now with mountfsd support we can do the same for the images settings,
so enable them and document them.
The description of ME= said "see above", but it was actually above the other
one. So change the order. But while reading this, I found it very hard to
understand. So reword things, hopefully in a way that is easier to understand.
The current behaviour is rather complex and unintuitive, but this description
just tries to describe it truthfully.
Implements DHCP option 15 (Domain Name) for systemd-networkd's DHCP
server, allowing administrators to configure the DNS default domain that
clients should use.
This addresses the feature request in issue #37077, where users needed
to manually configure domain names using
SendOption=15:string:example.com as a workaround.
This adds two new configuration options to the [DHCPServer] section:
- EmitDomain= (boolean): whether to send domain name to clients
- Domain= (string): the domain name to send (e.g., "example.com")
Example configuration:
[DHCPServer] EmitDomain=yes Domain=example.com
This eliminates the need for manual workarounds using
SendOption=15:string:...
Fixes#37077
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".
Lennart Poettering
Christoph Anton Mitterer
Daan De Meyer
Florian
dgengtek
Yu Watanabe
Frantisek Sumsal
Luca Boccassi
Ryan Brue
Daniel Foster
Luca Boccassi
Govind Venugopal
Zbigniew Jędrzejewski-Szmek
Taylan Kammer
Jelle van der Waa
Mike Yuan
Antonio Alvarez Feijoo
jsks