- Mention "/please-review" in the contributing guide
- Remove "needs-rebase" on push
- Don't add "please-review" if a green label is set
- Don't add please-review label to draft PRs
- Add please-review when a PR moves out of draft
- add missing assertions,
- use size_t for buffser size or memory index,
- handle empty input more gracefully,
- return the length or the result string,
- fix off-by-one issue when the prefix is already long enough.
When a pull request is opened/updated, add "please-review" and
remove a few other labels.
When a comment is made with /please-review on a PR. Add the
"please-review" label to the PR.
Since commit 1ad6e8b302, unsetting an environment
variable means restoring it to its default value.
However this doesn't work well when localed updates locale.conf. Indeed when a
variable is removed from that file, localed calls "UnsetAndSetEnvironment"
method which restores the default values of the unset variables obtained by
PID1 when it first read locale.conf. But since locale.conf has been updated,
these default values might be outdated and localed needs to instruct PID1 to
read locale.conf again.
Reloading PID1 configuration is quite an heavy operation for this purpose but
there's no other way unless we change again the meaning of "UnsetEnvironment"
or we introduce a new method that really unset an env variable.
That said given the fact that localed modifies locale.conf, it should have an
effect on PID1 default environment rather than on the environment explicitly
set by the user (m->client_manager).
This drops the special casing for s390 and other archs, which was
cargo-culted from glibc. Given it's not obvious why it exists, and is at
best an optimization let's simply avoid it, in particular as the archs
are relatively non-mainstream.
Inspired by: #25636
Let's allow using this in code shared between userspace and EFI mode.
Also, don't implement these functions via endianness conversions given
we don't actually want to convert endianess here.
A FreezeUnit operation can hang due to the presence of kernel threads
(see last 2 commits). Keeping the default configuration will mean the
system will hang for 25 seconds in suspend waiting for the response. 1.5
seconds should be sufficient for most cases.
The `frozen` state can be `0` while the processes are indeed frozen (see
last commit). Therefore do not respect cgroup.events when checking
whether thawing is necessary.
This is useful for operating in ephemeral, writable mode on any image,
including read-only ones. It also has the benefit of not keeping the
image file's filesystem busy.
Inspired by the discussions in #25648
Quoting "Trusted Platform Module Library - Part 3: Commands (Rev. 01.59)":
"pcrUpdateCounter – this parameter is updated by TPM2_PolicyPCR(). This value
may only be set once during a policy. Each time TPM2_PolicyPCR() executes, it
checks to see if policySession->pcrUpdateCounter has its default state,
indicating that this is the first TPM2_PolicyPCR(). If it has its default value,
then policySession->pcrUpdateCounter is set to the current value of
pcrUpdateCounter. If policySession->pcrUpdateCounter does not have its default
value and its value is not the same as pcrUpdateCounter, the TPM shall return
TPM_RC_PCR_CHANGED.
If this parameter and pcrUpdateCounter are not the same, it indicates that PCR
have changed since checked by the previous TPM2_PolicyPCR(). Since they have
changed, the previous PCR validation is no longer valid."
The TPM will return TPM_RC_PCR_CHANGED if any PCR value changes (no matter
which) between validating the PCRs binded to the enrollment and unsealing the
HMAC key, so this patch adds a retry mechanism in this case.
Fixes#24906
Sometimes a freeze operation can hang due to the presence of kernel
threads inside the unit cgroup (e.g. QEMU-KVM). This ensures that the
ThawUnit operation invoked by systemd-sleep at wakeup always thaws the
unit.
`FreezeUnit` can fail even when some units did got frozen, causing some
user units to be frozen. A possible symptom is `user@.service` being
frozen while still being able to log in over SSH.
When the user starts a program which elevates its permissions via setuid,
setgid, or capabilities set on the file, it may access additional information
which would then be visible in the coredump. We shouldn't make the the coredump
visible to the user in such cases.
Reported-by: Matthias Gerstner <mgerstner@suse.de>
This reads the /proc/<pid>/auxv file and attaches it to the process metadata as
PROC_AUXV. Before the coredump is submitted, it is parsed and if either
at_secure was set (which the kernel will do for processes that are setuid,
setgid, or setcap), or if the effective uid/gid don't match uid/gid, the file
is not made accessible to the user. If we can't access this data, we assume the
file should not be made accessible either. In principle we could also access
the auxv data from a note in the core file, but that is much more complex and
it seems better to use the stand-alone file that is provided by the kernel.
Attaching auxv is both convient for this patch (because this way it's passed
between the stages along with other fields), but I think it makes sense to save
it in general.
We use the information early in the core file to figure out if the program was
32-bit or 64-bit and its endianness. This way we don't need heuristics to guess
whether the format of the auxv structure. This test might reject some cases on
fringe architecutes. But the impact would be limited: we just won't grant the
user permissions to view the coredump file. If people report that we're missing
some cases, we can always enhance this to support more architectures.
I tested auxv parsing on amd64, 32-bit program on amd64, arm64, arm32, and
ppc64el, but not the whole coredump handling.
jcg
Yu Watanabe
Daan De Meyer
Zbigniew Jędrzejewski-Szmek
Thomas Haller
Edson Juliano Drosdeck
Franck Bui
Lennart Poettering
msizanoen1
Antonio Alvarez Feijoo
Jade Lovelace
Frantisek Sumsal
Space Meyer