IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
$TERM would generally be set if we're connected to a proper graphical terminal
emulator. In all other cases, in particular if $TERM is not set, we almost
certainly are not connected to something that can output emojis. In particular
the text console is unlikely to ever do it correctly.
So let's invert the check, and only write emojis if $TERM is set.
Fixes#25521.
(cherry picked from commit 7a14db9cfd)
This makes sure that after a server could not be contacted due to a
socket error, other (possibly working) NTP servers in the list of
configured NTP servers are (re-)tried.
Fixes#25728.
(cherry picked from commit 9b4e04f0cd)
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.
(cherry picked from commit 3e4d0f6cf9)
It may take a bit for newly introduced binaries/other files to get
properly integrated into the Rawhide specfile, so don't choke up in the
meantime when rpmbuild detects unpackaged files.
(cherry picked from commit ed7c45a8c8)
let's make sure we can probe file systems also when unprivileged:
instead of probing the partition block devices for file system
signatures, let's go via the original "whole" fd.
libblkid makes this easy actually, as it allows us to specify the
offset/size of the area to probe. And we have the partition
offsets/sizes anyway, so it's trivial for us to make use of.
This thus enables fs probing also when lacking privs and operating on
naked regular files without loopback devices or anything like this.
(cherry picked from commit c80c9079c8)
Let's explicitly flush the kernel's buffer cache on the whole block
device once we ran "mkfs". This is necessary, because partition and
whole block devices maintain separate buffer caches, and thus writing
to one will not be visible on the other if cached there already, until
the latter's cache is explicitly flushed.
This is preparation for later adding support for probing file sytems
also if we have no open partition block devices, and hence want to use
the whole block device instead.
(cherry picked from commit 59a4c0d7e3)
Let's extend the test further, and try the codepaths where we do not
pin/add the partition block devices (i.e. which is the codepaths we use
when running without privs)
(cherry picked from commit 9f2d9a4aab)
Let's verify that we properly created the file systems once we did so.
And tets this way that our dissector works correctly.
(cherry picked from commit 02c15120a1)
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.
(cherry picked from commit 3d19e122cf)
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.
(cherry picked from commit 7fcd269784)
`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.
(cherry picked from commit efa736d383)
I am hitting the rate limit on a busy system with low resources, and
it stalls the boot process which is Very Bad (TM).
(cherry picked from commit 24a4542cfa)
Included in the backport because it's a workaround for an issue introduced
in v249.
In both cases, the json string is short, so we can print it, which is useful
for diagnosing invalid data in packages. But we need escape non-printable
characters.
https://bugzilla.redhat.com/show_bug.cgi?id=2152685
I went over the rest of the codebase, and it seems that other calls to
json_parse() don't have this problem.
(cherry picked from commit c5966ab5bf)
Let's enforce that callers pass AT_FDCWD as read_dfd to load_credential()
to avoid an assert() in read_full_file_full() if read_dfd is -1.
(cherry picked from commit 661e4251a5)
We would execute up to four hwdb match patterns (+ the keyboard builtin):
After the first hit, we would skip the other patterns, because of the GOTO="evdev_end"
action.
57bb707d48 (rules: Add extended evdev/input match
rules for event nodes with the same name), added an additional match with
":phys:<phys>:ev:<ev>" inserted. This breaks backwards compatibility for user
hwdb patterns, because we quit after the first match.
In general hwdb properties are "additive". We often have a general rule that
matches a wider class and then some specific overrides. E.g. in this particular
case, we have a match for all trackpoints, and then a bunch of model-specific
settings.
So let's change the rules to try all the match patterns and combine the
received properties. We execute builtin-keyboard once at the end, if there was
at least one match.
Fixes#25698. Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2152226.
This also impacts other cases which I think would be very confusing for users.
Since we quit after a first successful match, if we had e.g. a match for
'evdev:input:b*v*p*' in out database, and the user added a match using
'evdev:name:*', which is the approach we document in the .hwdb files and which
users quite often use, it would be silently ignored. What's worse, if we added
our 'evdev:input:b*v*p*' match at a later point, user's match would stop
working. If we combine all the properties, we get more stable behaviour.
(cherry picked from commit 953c928c24)
Then, this drops ID128_PLAIN_OR_UNINIT. Also, this renames
Id128Format -> Id128FormatFlag, and make it bitfield.
Fixes#25634.
(cherry picked from commit 057bf780e9)
If an attribute is read but the value is not used (i.e. ret_value is NULL),
then sd_device_get_sysattr_value() mistakenly frees the read data even though
it is cached internally.
Fixes a bug introduced by acfc2a1d15.
Fixes#25702.
(cherry picked from commit eb18e7b782)
This effectively reverts 5d0030310c.
With the commit 5d0030310c, networkd manages
addresses with the detailed hash and compare functions. But that causes
networkd cannot detect address update by the kernel or an external tool.
See issue
https://github.com/systemd/systemd/issues/481#issuecomment-1328132401.
With this commit, networkd (again) manages addresses in the way that the
kernel does. Hence, we can correctly detect address update.
(cherry picked from commit 42f8b6a808)
Btrfs quotas are actually being enabled in systemd-importd via
setup_machine_directory(), not in systemd-{import,pull} where those
environment variables are checked. Therefore, also check them in
systemd-importd and avoid enabling quotas if requested by the user.
Fixes: #18421Fixes: #15903Fixes: #24387
(cherry picked from commit c7779a61ac)
Non-negative return values of setup_machine_directory() were never used
and never had clear meaning, so do not distinguish between various
non-error conditions and just return 0 in all cases.
(cherry picked from commit e9231901a2)
Doing the reconnect dance on some real firmware creates huge delays on
boot. This should not be needed anymore as we now ask the firmware to
make console devices and xbootldr partitions available explicitly in a
more targeted fashion.
Fixes: #25510
(cherry picked from commit f6d59e2ebf)
Note: I reapplied the original patch by hand, hopefully breaking nothing
in the process. In 'main' open_volume() was changed to call either
vmm_open() or open_volume(), and the call to reconnect_all_drivers() was
moved to vmm_open(). Here, that call is moved to the point where open_volume()
is called, guarded by is_direct_boot(().
This fixes an issue introduced by af2aea8bb6.
When an outdated address or route is passed to link_request_address()/route(),
then they return 0 and the address or route will not be assigned. Such
situation can happen when we receive RA with zero lifetime. In that
case, we should not unset Link.ndisc_configured flag, otherwise even
no new address nor route will assigned, the interface will enter to the
configuring state, and unnecessary DBus property change is emit and the state
file will be updated. That makes resolved or timesyncd triggered to
reconfigure the interface.
Fixes#25456.
(cherry picked from commit d9a95033bf)
Curently, these two flags were implied by dissect_loop_device(), but
that's not right, because this means systemd-gpt-auto-generator will
dissect the root block device with these flags set and that's not
desirable: the generator should not cause the partition devices to be
created (we don't intend to use them right-away after all, but expect
udev to find/probe them first, and then mount them though .mount units).
And there's no point in opening the partition devices, since we do not
intend to mount them via fds either.
Hence, rework this: instead of implying the flags, specify them
explicitly.
While we are at it, let's also rename the flags to make them more
descriptive:
DISSECT_IMAGE_MANAGE_PARTITION_DEVICES becomes
DISSECT_IMAGE_ADD_PARTITION_DEVICES, since that's really all this does:
add the partition devices via BLKPG.
DISSECT_IMAGE_OPEN_PARTITION_DEVICES becomes
DISSECT_IMAGE_PIN_PARTITION_DEVICES, since we not only open the devices,
but keep the devices open continously (i.e. we "pin" them).
Also, drop the DISSECT_IMAGE_BLOCK_DEVICE combination flag, since it is
misleading, i.e. it suggests it was appropriate to specify on all
dissected blocking devices, but that's precisely not the case, see the
systemd-gpt-auto-generator case. My guess is that the confusion around
this was actually the cause for this bug we are addressing here.
Fixes: #25528
(cherry picked from commit 73d88b806b)
- 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.
(cherry picked from commit c21b316964)
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
(cherry picked from commit 0254e4d66a)
Inspired by #25664: let's check explicitly for NULL everywhere we do one
of those getXYZcon() calls.
We usually turn this into EOPNOTSUPP, as when selinux is off (which is
supposed to be the only case this can happen according to selinux docs)
we otherwise return EOPNOTSUPP in that case.
Note that in most cases we have an explicit mac_selinux_use() call
beforehand, hence this should mostly not be triggerable codepaths.
(cherry picked from commit af614e45c3)
getpidcon() might set con to NULL, even when it returned a 0 return
code[0]. The subsequent strlen(con) will then cause a segfault.
Alternatively the behaviour could also be changed in getpidcon. I
don't know whether the libselinux folks are comitted to the current
behaviour, but the getpidcon man page doesn't really make it obvious
this case could happen.
[0] fb7f35495f/libselinux/src/procattr.c (L155-L158)
(cherry picked from commit ff868eaade)
