The interface requires services to write to the cgroup file to activate notifications,
but with ProtectControlGroups=yes we make it read-only. Add a writable bind mount.
Follow-up for 6bb0084204
Use the flags MEMFD_EXEC or MEMFD_NOEXEC_SEAL as applicable.
These warnings instruct the kernel wether the memfd is executable or
not.
Without specifying those flags the kernel will emit the following
warning since version 6.3,
commit 105ff5339f49 ("mm/memfd: add MFD_NOEXEC_SEAL and MFD_EXEC"):
kernel: memfd_create() without MFD_EXEC nor MFD_NOEXEC_SEAL, pid=1 'systemd'
Now that we always create PE images with a non-zero image base we cannot
run into this issue anymore. Any tool that still uses the old hard-coded
section offsets will end up creating bad images with sections below the
image base. objcopy will warn about this and any PE loader will simply
refuse to load such an image. Meanwhile updated tools do not use
hard-coded offsets anymore.
Let's avoid any ambiguities around paths, and make them absolute when
accepting them, like we do in most our tools now. This makes us
independent of the current working directory and allows us to change it
without issues or pass around the paths elsewhere if need be.
Those are rather specialized bits of information, useful mostly for debugging.
I use cgls quite often but never had the need to use either of those…
But they take up a significant amount of screen real estate, esp. when
executed as root:
-.slice
├─user.slice (#1683)
│ → user.invocation_id: 74b0bd1258c5485eb969016384e0d06a
│ → trusted.invocation_id: 74b0bd1258c5485eb969016384e0d06a
│ └─user-1000.slice (#6488)
│ → user.invocation_id: b0261a14fe74490d9a9d5266c52cceb6
│ → trusted.invocation_id: b0261a14fe74490d9a9d5266c52cceb6
│ ├─user@1000.service … (#6590)
│ │ → user.invocation_id: 9e1fb54ad07940d8b92c33c81d169f11
│ │ → user.delegate: 1
│ │ → trusted.invocation_id: 9e1fb54ad07940d8b92c33c81d169f11
│ │ → trusted.delegate: 1
│ │ ├─session.slice (#6874)
...
Let's not show them by default, so we can show more cgroups.
(Also, on a terminal, we already highlight delegate units via underlining and
an ellipsis, so 'user.delegate:1' is redundant.)
This ensure messages from PID1 regarding a unit also contain those
fields. For example, portable services have PORTABLE=<image> as
extra fields, which is useful to identify which version of a portable
image produced a log message like an error or an oomd kill.
Let image_install figures the binary paths out itself as not all distributions
ship the mkfs.* tools in the same location. For example openSUSE ships
mksquashfs in /usr/bin/.
This fixes the tablet buttons on the Thinkpad X200 Tablet.
My Lenovo ThinkPad X200 Tablet is called "ThinkPadX200T" instead of "ThinkPadX200Tablet":
```
$ cat /sys/devices/virtual/dmi/id/modalias
dmi:bvnLENOVO:bvr7WET71WW(3.21):bd11/29/2012:br3.33:efr1.6:svnLENOVO:pn7453WVK:pvrThinkPadX200T:rvnLENOVO:rn7453WVK:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:sku:
```
This patch makes both strings work correctly to support the extra tablet keys.
For nspawn and services we first turn off two-way propagation of mounts
from host to sandbox via MS_SLAVE, and then set MS_SHARED again, so that
we create a new mount prop peer group again, and that we provide
behaviour similar to what we provide on the host further down the tree.
Let's do the same in detach_mount_namespace(), which we use for the
temporary mounts in the implementation of --image= in various tools.
This doesn't fix any immediate issue, but ensures we expose somewhat
systematic behaviour: whenever we detach mount namespaces we always set
things back to MS_SLAVE in the child.
ExecContext has a field that controls the mount propagation flag of the
mounts in the resulting namespace. This is exposed as "MountFlags="
which is super confusing, as it suggests one could control more than
propagation, and that it was actually a flags field. It's an enum
though only, and nothing else.
We might want to rename this externally one day, but given the compat
kludges this requires and the fact this is somewhat nichey it might not
be worth it. But internally let's rename it, as it makes things much
easier to grok, in particular as part of the codebase already exposed
the concept as mount_propagation_flag.
No actual code flow changes, just some renaming.