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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This makes the naming more consistent: we now have
bootctl systemd-efi-options,
$SYSTEMD_EFI_OPTIONS
and the SystemdOptions EFI variable.
(SystemdEFIOptions would be redundant, because it is only used in the context
of efivars, and users don't interact with that name directly.)
bootctl is adjusted to use 2sp indentation, similarly to systemctl and other
programs.
Remove the prefix with the old name from 'bootctl systemd-efi-options' output,
since it's redundant and we don't want the old name anyway.
On some systems with lots of devices, device probing for certain drivers can
take a very long time. If systemd-udevd detects a timeout and kills the worker
running modprobe using SIGKILL, some devices will not be probed, or end up in
unusable state. The --event-timeout option can be used to modify the maximum
time spent in an uevent handler. But if systemd-udevd exits, it uses a
different timeout, hard-coded to 30s, and exits when this timeout expires,
causing all workers to be KILLed by systemd afterwards. In practice, this may
lead to workers being killed after significantly less time than specified with
the event-timeout. This is particularly significant during initrd processing:
systemd-udevd will be stopped by systemd when initrd-switch-root.target is
about to be isolated, which usually happens quickly after finding and mounting
the root FS.
If systemd-udevd is started by PID 1 (i.e. basically always), systemd will
kill both udevd and the workers after expiry of TimeoutStopSec. This is
actually better than the built-in udevd timeout, because it's more transparent
and configurable for users. This way users can avoid the mentioned boot problem
by simply increasing StopTimeoutSec= in systemd-udevd.service.
If udevd is not started by systemd (standalone), this is still an
improvement. udevd will kill hanging workers when the event timeout is
reached, which is configurable via the udev.event_timeout= kernel
command line parameter. Before this patch, udevd would simply exit with
workers still running, which would then become zombie processes.
With the timeout removed, the sd_event_now() assertion in manager_exit() can be
dropped.
Discussed in #13743, the -.service semantic conflicts with the
existing root mount and slice names, making this feature not
uniformly extensible to all types. Change the name to be
<type>.d instead.
Updating to this format also extends the top-level dropin to
unit types.
I think we can mention that systemd-resolved is able to validate IP
address certificates and prefer TLS 1.3 before TLS 1.2 now.
Also the `machinectl reboot` command actually works now.
Signed-off-by: Christian Rebischke <chris@nullday.de>
In the past, we asked people to open a security bug on one of the "big"
distros. This worked OK as far as getting bugs reported and notifying some
upstream developers went. But we always had trouble getting information to
all the appropriate parties, because each time a bug was reported, a big
thread was created, with a growing CC list. People who were not CCed early
enough were missing some information, etc.
To clean this up, we decided to create a private mailing list. The natural
place would be freedesktop.org, but unfortunately the request to create a
mailing list wasn't handled
(https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/134). And even
if it was, at this point, if there was ever another administrative issue, it
seems likely it could take months to resolve. So instead, we asked for a list
to be created on the redhat mailservers.
Please consider the previous security issue reporting mechanisms rescinded, and
send any senstive bugs to systemd-security@redhat.com.
Current kernels with BFQ scheduler do not yet set their IO weight
through "io.weight" but through "io.bfq.weight" (using a slightly
different interface supporting only default weights, not per-device
weights). This commit enables "IOWeight=" to just to that.
This patch may be dropped at some time later.
Github-Link: https://github.com/systemd/systemd/issues/7057
Signed-off-by: Kai Krakow <kai@kaishome.de>
waitid(2) and the libc function signature calls this "exit status", and
uses "exit code" for something different. Let's stick to the same
nomenclature hence.
This makes ping(8) work without CAP_NET_ADMIN and CAP_NET_RAW because
those aren't effective inside rootless Podman containers.
It's quite useful when using OSTree based operating systems like Fedora
Silverblue, where development environments are often set up using
rootless Podman containers with helpers like Toolbox [1]. Not having
a basic network utility like ping(8) work inside the development
environment can be inconvenient.
See:
https://lwn.net/Articles/422330/http://man7.org/linux/man-pages/man7/icmp.7.htmlhttps://github.com/containers/libpod/issues/1550
The upper limit of the range of group identifiers is set to 2147483647,
which is 2^31-1. Values greater than that get rejected by the kernel
because of this definition in linux/include/net/ping.h:
#define GID_T_MAX (((gid_t)~0U) >> 1)
That's not so bad because values between 2^31 and 2^32-1 are reserved
on systemd-based systems anyway [2].
[1] https://github.com/debarshiray/toolbox
[2] https://systemd.io/UIDS-GIDS.html#summary
Change the resolved.conf Cache option to a tri-state "no, no-negative, yes" values.
If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s (See 201d995),
however, there are several use cases on which this condition is not acceptable (See systemd#5552 comments)
and the only workaround would be to disable cache entirely or flush it , which isn't optimal.
This change adds the 'no-negative' option when set it avoids putting in cache
negative answers but still works the same heuristics for positive answers.
Signed-off-by: Jorge Niedbalski <jnr@metaklass.org>
Make possible to set NUMA allocation policy for manager. Manager's
policy is by default inherited to all forked off processes. However, it
is possible to override the policy on per-service basis. Currently we
support, these policies: default, prefer, bind, interleave, local.
See man 2 set_mempolicy for details on each policy.
Overall NUMA policy actually consists of two parts. Policy itself and
bitmask representing NUMA nodes where is policy effective. Node mask can
be specified using related option, NUMAMask. Default mask can be
overwritten on per-service level.
These make sense to be explicitly set at 0 (which has a different effect
than the default, since it can affect processing of `DefaultMemoryXXX`).
Without this, it's not easily possible to relinquish memory protection
for a subtree, which is not great.
Let's be safe, rather than sorry. This way DynamicUser=yes services can
neither take benefit of, nor create SUID/SGID binaries.
Given that DynamicUser= is a recent addition only we should be able to
get away with turning this on, even though this is strictly speaking a
binary compatibility breakage.
"BOOT" is misleading, because it sounds like this refers to /boot or $BOOT,
when in fact it refers to some subdirectory. Those variable names are purely
interal, so we can change them. $BOOT_DIR_ABS was used in NEWS, but it should
not be (because it is an internal detail), so the old NEWS entry is reworded to
use "entry directory".
Previously, this system call was included in @system-service since it is
a "getter" only, i.e. only queries information, and doesn't change
anything, and hence was considered not risky.
However, as it turns out, mincore() is actually security sensitive, see
the discussion here:
https://lwn.net/Articles/776034/
Hence, let's adjust the system call filter and drop mincore() from it.
This constitues a compatibility break to some level, however I presume
we can get away with this as the systemcall is pretty exotic. The fact
that it is pretty exotic is also reflected by the fact that the kernel
intends to majorly change behaviour of the system call soon (see the
linked LWN article)
These sysctls were added in Linux 4.19 (torvalds/linux@30aba6656f), and
we should enable them just like we enable the older hardlink/symlink
protection since v199. Implements #11414.
Nitpicky, but we've used a lot of random spacings and names in the past,
but we're trying to be completely consistent on "cgroup vN" now.
Generated by `fd -0 | xargs -0 -n1 sed -ri --follow-symlinks 's/cgroups? ?v?([0-9])/cgroup v\1/gI'`.
I manually ignored places where it's not appropriate to replace (eg.
"cgroup2" fstype and in src/shared/linux).
This reverts commit edda44605f.
The kernel explicitly supports resuming with a different kernel than the one
used before hibernation. If this is something that shouldn't be supported, the
place to change this is in the kernel. We shouldn't censor something that this
exclusively in the kernel's domain.
People might be using this to switch kernels without restaring programs, and
we'd break this functionality for them.
Also, even if resuming with a different kernel was a bad idea, we don't really
prevent that with this check, since most users have more than one kernel and
can freely pick a different one from the menu. So this only affected the corner
case where the kernel has been removed, but there is no reason to single it
out.
From WordNet (r) 3.0 (2006) [wn]:
time-out
n 1: a brief suspension of play; "each team has two time-outs left"
From The Free On-line Dictionary of Computing (18 March 2015) [foldoc]:
timeout
A period of time after which an error condition is raised if
some event has not occured. A common example is sending a
message. If the receiver does not acknowledge the message
within some preset timeout period, a transmission error is
assumed to have occured.
This switches the RFC3704 Reverse Path filtering from Strict mode to Loose
mode. The Strict mode breaks some pretty common and reasonable use cases,
such as keeping connections via one default route alive after another one
appears (e.g. plugging an Ethernet cable when connected via Wi-Fi).
The strict filter also makes it impossible for NetworkManager to do
connectivity check on a newly arriving default route (it starts with a
higher metric and is bumped lower if there's connectivity).
Kernel's default is 0 (no filter), but a Loose filter is good enough. The
few use cases where a Strict mode could make sense can easily override
this.
The distributions that don't care about the client use cases and prefer a
strict filter could just ship a custom configuration in
/usr/lib/sysctl.d/ to override this.
After discussions with kernel folks, a system with memcg really
shouldn't need extra hard limits on file descriptors anymore, as they
are properly accounted for by memcg anyway. Hence, let's bump these
values to their maximums.
This also adds a build time option to turn thiss off, to cover those
users who do not want to use memcg.
Back in 2012 the project was renamed, see the release notes for v 0.105
[https://cgit.freedesktop.org/polkit/tree/NEWS#n754]. Let's update our
documentation and comments to do the same. Referring to PolicyKit is confusing
to users because at the time the polkit api changed too, and we support the new
version. I updated NEWS too, since all the references to PolicyKit there were
added after the rename.
"PolicyKit" is unchanged in various URLs and method call names.
This is an additional synchronization point normally not needed. Hence,
let's make it passive, i.e. pull it in from the unit which wants to be
ordered before the update service rather than by the update service
itself.
We really should try to be as precise as possible here. Saying
"your interfaces might be renamed" scares the shit of out people,
for obvious reasons. This change only touches some niche cases
fortunately, let's make this clear.
