| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
systemd-run/at/crontab and such things
|
|
|
|
|
| |
When the --force flag is used, do not insist that the extension-release
file has to match the extension image name
|
| |
|
|
|
|
|
|
| |
activation by timer unit
Same as path unit, best effort.
|
|
|
|
|
|
|
|
| |
When a service is triggered by a path unit, pass the
path unit name and the path that triggered it via env vars
to the spawned processes.
Note that this is best-effort, as there might be many triggers
at the same time, but we only get woken up by one.
|
|
|
|
|
|
|
|
|
| |
Something *is* similar
Something *works* similarly
Something does something, similarly to how something else does something
See https://sites.ulethbridge.ca/roussel/2017/11/29/similar-and-similarly-are-they-similar/
for a clear explanation.
|
|
|
|
| |
fix #2114
|
|
|
|
| |
Fixes: #24056
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This imports credentials also via SMBIOS' "OEM vendor string" section,
similar to the existing import logic from fw_cfg.
Functionality-wise this is very similar to the existing fw_cfg logic,
both of which are easily settable on the qemu command line.
Pros and cons of each:
SMBIOS OEM vendor strings:
- pro: fast, because memory mapped
- pro: somewhat VMM independent, at least in theory
- pro: qemu upstream sees this as the future
- pro: no additional kernel module needed
- con: strings only, thus binary data is base64 encoded
fw_cfg:
- pro: has been supported for longer in qemu
- pro: supports binary data
- con: slow, because IO port based
- con: only qemu
- con: requires qemu_fw_cfg.ko kernel module
- con: qemu upstream sees this as legacy
|
|
|
|
| |
used.
|
|
|
|
|
|
|
| |
https://www.kernel.org/ links to https://docs.kernel.org/ for the documentation.
See https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=ebc1c372850f249dd143c6d942e66c88ec610520
These URLs are shorter and nicer looking.
|
|
|
|
| |
Instead of using "*.txt" as reference name, use the actual destination title.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts PR #22587 and its follow-up commit. More specifically,
2299b1cae32c1fb8911da0ce26efced68032f4f8 (partially),
e176f855278d5098d3fecc5aa24ba702147d42e0,
ceb46a31a01b3d3d1d6095d857e29ea214a2776b, and
51bb9076ab8c050bebb64db5035852385accda35.
The PR was merged without final approval, and has several issues:
- OSS fuzz reported issues in the conf parser,
- It calls synchrnous netlink call, it should not be especially in PID1,
- The importance of NFTSet for CGroup and DynamicUser may be
questionable, at least, there was no justification PID1 should support
it.
- For networkd, it should be implemented with Request object,
- There is no test for the feature.
Fixes #23711.
Fixes #23717.
Fixes #23719.
Fixes #23720.
Fixes #23721.
Fixes #23759.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New directive `DynamicUserNFTSet=` provides a method for integrating
configuration of dynamic users into firewall rules with NFT sets.
Example:
```
table inet filter {
set u {
typeof meta skuid
}
chain service_output {
meta skuid != @u drop
accept
}
}
```
```
/etc/systemd/system/dunft.service
[Service]
DynamicUser=yes
DynamicUserNFTSet=inet:filter:u
ExecStart=/bin/sleep 1000
[Install]
WantedBy=multi-user.target
```
```
$ sudo nft list set inet filter u
table inet filter {
set u {
typeof meta skuid
elements = { 64864 }
}
}
$ ps -n --format user,group,pid,command -p `pgrep sleep`
USER GROUP PID COMMAND
64864 64864 55158 /bin/sleep 1000
```
|
| |
|
|
|
|
|
|
|
|
|
| |
I don't know why this didn't occur to me earlier, but of course, it
*has* to be this data.
(This replaces some German prose about Berlin, that i guess only very
few people will get. With the new blob I think we have a much broader
chance of delivering smiles.)
|
| |
|
| |
|
|
|
|
|
|
| |
We use authenticated encryption, and that deserves mention. This in
particular relevant as the fact they are authenticated makes the
credentials useful as initrd parameterization items.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
Unprivileged overlayfs is supported since Linux 5.11. The only
change needed to get ExtensionDirectories to work is to avoid
hard-coding the staging directory to the system manager runtime
directory, everything else just works (TM).
|
|
|
|
|
|
|
|
|
|
|
| |
OnFailure/OnSuccess
Remove the list logic, and simply skip passing metadata if more than one
unit triggered an OnFailure/OnSuccess handler.
Instead of a single env var to loop over, provide each separate item
as its own variable.
Fixes https://github.com/systemd/systemd/issues/22370
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only piece missing was to somehow make /proc appear in the
new user+mount namespace. It is not possible to mount a new
/proc instance, not even with hidepid=invisible,subset=pid, in
a user namespace unless a PID namespace is created too (and also
at the same time as the other namespaces, it is not possible to
mount a new /proc in a child process that creates a PID namespace
forked from a parent that created a user+mount namespace, it has
to happen at the same time).
Use the host's /proc with a bind-mount as a fallback for this
case. User session services would already run with it, so
nothing is lost.
|
|
|
|
| |
Fixes #22432.
|
|
|
|
| |
Remove incorrect claim that C escapes (such as \t and \n) are recognized and that control characters are disallowed. Specify the allowed characters and escapes with single quotes, with double quotes, and without quotes.
|
|
|
|
|
|
|
|
| |
Add a new setting that follows the same principle and implementation
as ExtensionImages, but using directories as sources.
It will be used to implement support for extending portable images
with directories, since portable services can already use a directory
as root.
|
| |
|
|
|
|
|
| |
Decsribe when $MONITOR_METADATA will be set and how it's contents are
defined.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Let's not mention a redundant setting of "none". Let's instead only
mention "best-effort", which is the same. Also mention the default
settings properly.
(Also, while we are at it, don#t document the numeric alias, that's
totally redundant and harder to use, so no need to push people towards
it.)
|
|
|
|
| |
Update also manual page to explain how the transition can still fail.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When combined with a tmpfs on /run or /var/lib, allows to create
arbitrary and ephemeral symlinks for StateDirectory or RuntimeDirectory.
This is especially useful when sharing these directories between
different services, to make the same state/runtime directory 'backend'
appear as different names to each service, so that they can be added/removed
to a sharing agreement transparently, without code changes.
An example (simplified, but real) use case:
foo.service:
StateDirectory=foo
bar.service:
StateDirectory=bar
foo.service.d/shared.conf:
StateDirectory=
StateDirectory=shared:foo
bar.service.d/shared.conf:
StateDirectory=
StateDirectory=shared:bar
foo and bar use respectively /var/lib/foo and /var/lib/bar. Then
the orchestration layer decides to stop this sharing, the drop-in
can be removed. The services won't need any update and will keep
working and being able to store state, transparently.
To keep backward compatibility, new DBUS messages are added.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
which binaries executed by Exec*= should be found
Currently there does not exist a way to specify a path relative to which
all binaries executed by Exec should be found. The only way is to
specify the absolute path.
This change implements the functionality to specify a path relative to which
binaries executed by Exec*= can be found.
Closes #6308
|
|
|
|
|
|
|
|
|
| |
They are somewhat similar, but not easy to discover, esp. considering that
they are described in different pages.
For PrivateDevices=, split out the first paragraph that gives the high-level
overview. (The giant second paragraph could also use some heavy editing to break
it up into more digestible chunks, alas.)
|
| |
|
|
|
|
|
|
| |
There is some inconsistency, partially caused by the awkward naming
of the docs/ pages. But let's be consistent and use the "official" title.
If we ever change plural↔singular, we should use the same form everywhere.
|
|
|
|
| |
Fixes #20297.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The mount option has special meaning when SELinux is enabled. To make
NoNewPrivileges=yes not break SELinux enabled systems, let's not set the
mount flag on such systems.
|
|
|
|
|
|
|
|
|
| |
This reverts commit 1753d3021564671fba3d3196a84da657d15fb632.
Let's re-enable that feature now. As reported when the original commit
was merged, this causes some trouble on SELinux enabled systems. So,
in the subsequent commit, the feature will be disabled when SELinux is enabled.
But, anyway, this commit just re-enable that feature unconditionally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d8e3c31bd8e307c8defc759424298175aa0f7001.
A poorly documented fact is that SELinux unfortunately uses nosuid mount flag
to specify that also a fundamental feature of SELinux, domain transitions, must
not be allowed either. While this could be mitigated case by case by changing
the SELinux policy to use `nosuid_transition`, such mitigations would probably
have to be added everywhere if systemd used automatic nosuid mount flags when
`NoNewPrivileges=yes` would be implied. This isn't very desirable from SELinux
policy point of view since also untrusted mounts in service's mount namespaces
could start triggering domain transitions.
Alternatively there could be directives to override this behavior globally or
for each service (for example, new directives `SUIDPaths=`/`NoSUIDPaths=` or
more generic mount flag applicators), but since there's little value of the
commit by itself (setting NNP already disables most setuid functionality), it's
simpler to revert the commit. Such new directives could be used to implement
the original goal.
|